With the addition of function line number handling, the overhead of
the compile functions is no longer negligible. We tend to compile
the same pieces of code over and over again so wrapping a cache around
this is beneficial and removes the overhead of line numbered functions.
Life cycle of a cache using a global like this is in theory problematic
although in reality unlikely to be an issue. It can be dealt with
if/as/when we deal with the other global caches.
(Bitbake rev: 98d7002d1dca4b62042e1589fd5b9b3805d57f7a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you break the internals of better_exec(), you get a very weird
error about tb_next not being a method of None. Fix this by checking
we can step back a trace level.
(Bitbake rev: 1d710ed484f68fca0789022dde7ba877b9a894f5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the following improvements to edit_bblayers_conf():
* Support ~ in BBLAYERS entries
* Handle where BBLAYERS items are added over multiple lines with +=
instead of one single long item
Also add some comments documenting the function arguments and return
values as well as a set of bitbake-selftest tests.
(This function is used by the bitbake-layers add, remove and
layerindex-fetch subcommands, as well as devtool when adding the
workspace layer).
(Bitbake rev: e9a0858023c7671e30cc8ebb08496304b7f26b31)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you tried to delete the variable on the first line passed to
edit_metadata() this failed because the logic for trimming extra blank
lines didn't expect the list to be empty at that point - fix that bad
assumption.
(Bitbake rev: 8bce6fefdc5c046b916588962a2b429c0f648133)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to BB_TASK_NICE_LEVEL, add BB_TASK_IONICE_LEVEL which allows the ioprio
of tasks to be adjusted. This is in response to various qemu runtime timeouts
which have been witnessed on the autobuilder, seemingly due to IO starvation (we
already use NICE_LEVEL to adjust tasks). This has a fairly urgent need to deal
with certain 'random' failures we're seeing on the autobuilders in testing.
The format of the data in the variable is BB_TASK_IONICE_LEVEL = "<class>.<prio>".
For <class>, 2 is best effort (the default), 1 is real time and 3 is idle. You'd
need superuser privileges to use realtime. The <prio> value is a default of 4,
and can be set between 0 and 7 with 7 being lowest priority and 0 the highest.
The user can set this freely with normal privileges
Note that in order for this to take effect, you need the cfq scheduler selected
for the backing block device.
We could use nice wrapper functions for ioprio from modules like psutil however
that would complicate bitbake dependencies. This version has some magic numbers
but works on the main 32 and 64 bit x86 build architectures and can easily be
extended if ever needed. When we move to python 3.x, we can likely replace this
with standard calls.
(Bitbake rev: b9471ad147b102c45d65f5ffd9521864df7ff9c1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prevent edit_bblayers_conf() from adding layer(s) multiple times. This
happened when BBLAYERS variable was "listed" multiple times in
bblayer.conf - i.e. the configuration was split into multiple separate
assignments.
[YOCTO #8316]
(Bitbake rev: 5e423237f9f4ff7e7e03bf066b0142ba4bd82219)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new bb.utils.signal_on_parent_exit() function so that a process
can register to recieve a signal when the parent dies. There is no
POSIX standard for this and the implementation is Linux specific.
Alternatives would be having an open pipe or polling os.getppid()
for changes but this seems more effective and less invasive to most
of bitbake's code structure.
We need to be able to determine when parents die to ensure child
processes stop running in a variety of circumstances to avoid
locks being held and ensure clean shutdown.
Roughly based on https://gist.github.com/evansd/2346614
(Bitbake rev: 34974f5e30e9b09c016481e4c81c156a5f379784)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake utils' movefile is now prone to malform the destination
file with duplicated file name strings. Fixing it to force a file
name append iff the dest argument is a dir not a file name
(Bitbake rev: 38dd27f7191da002a16c561be3790ce487045b01)
Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When moving a file via the os.rename function, it was missing the
destination file name which caused an OSError
[YOCTO#8180]
(Bitbake rev: b147ba0341d87e077bd2b09ef4355976ecd2d26b)
Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake-layers needs to map recipe and class files to the layer they
came from within the show-recipes and show-overlayed commands. However,
it turns out that mapping a file to the layer it came from is not as
trivial as it might seem. To do it properly we need to match the path to
an entry in BBFILES then map that to the collection name using
BBFILE_PATTERN, then map that to the actual layer using variable
history. If it doesn't match any entry in BBFILES, then we can fall back
to BBFILE_PATTERN (to handle classes and conf files).
This fixes the layer name not showing up properly in the output of the
show-recipes and show-overlayed commands for recipes in layers such as
meta-intel that have subdirectories in BBFILE_PATTERN. It also fixes the
priority not showing up in show-layers for such layers.
As part of this I've added a function to VariableHistory which for a
space-separated list variable gives you a dict mapping the items added
to the files in which they were added. I've also fixed
bb.utils.get_file_layer() and reduced some of the duplication by using
this function in bitbake-layers. Also fixes the priority not showing up
for layers such as meta-intel
Fixes [YOCTO #8160].
(Bitbake rev: e852f6cabd7489585477ab567a1afeb2252377ac)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the PR server or indeed any other child process takes some time to
exit (which it sometimes does when saving its database), it can end up
holding bitbake.lock after the UI exits, which led to errors if you ran
bitbake commands successively - we saw this when running the PR server
oe-selftest tests in OE-Core. The recent attempt to fix this wasn't
quite right and ended up breaking memory resident bitbake. This time we
close the lock file when cooker shuts down (inside the UI process)
instead of unlocking it, and this is done in the cooker code rather than
the actual UI code so it doesn't matter which UI is in use. Additionally
we report that we're waiting for the lock to be released, using lsof or
fuser if available to list the processes with the lock open.
The 'magic' in the locking is due to all spawned subprocesses of bitbake
holding an open file descriptor to the bitbake.lock. It is automatically
unlocked when all those fds close the file (as all the processes terminate).
We close the UI copy of the lock explicitly, then close the server process
copy, any remaining open copy is therefore some proess exiting.
(The reproducer for the problem is to set PRSERV_HOST = "localhost:0"
and add a call to time.sleep(20) after self.server_close() in
lib/prserv/serv.py, then run "bitbake -p; bitbake -p" ).
Cleanup work done by Paul Eggleton <paul.eggleton@linux.intel.com>.
This reverts bitbake commit 69ecd15aece54753154950c55d7af42f85ad8606 and
e97a9f1528d77503b5c93e48e3de9933fbb9f3cd.
(Bitbake rev: a29780bd43f74b7326fe788dbd65177b86806fcf)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the cooker parsing processes each dump an individual profile
which is ok, but means absolute numbers of function calls for a given load
can be tricky to determine as parsing of recipes may go to different pool
threads on different runs.
This change collects up the individual thread parsing results and processes
them into one profile output. The profile processing function in utils
needed tweaks to allow this to work.
(Bitbake rev: d3d2541aacd1ea560da0d8b25a3ea3f0563dee70)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix several bugs and add some useful enhancements to make this into a
more generic metadata editing function:
* Support modifying function values (name must be specified ending with
"()")
* Support dropping values by returning None as the new value
* Split out edit_metadata() function to provide same functionality
on a list/iterable
* Pass operation to callback and allow function to return them
* Pass current output lines to callback so they can be modified
* Fix handling of single-quoted values
* Handle :=, =+, .=, and =. operators
* Support arbitrary indent string
* Support indenting by length of assignment (by specifying -1)
* Fix typo in variablename - intentspc -> indentspc
* Expand function docstring to cover arguments / usage
* Add a parameter to enable matching names with overrides applied
* Add some bitbake-selftest tests
Note that this does change the expected signature of the callback
function. The only known caller is in lib/bb/utils.py itself; I doubt
anyone else has made extensive use of this function yet.
(Bitbake rev: 20059e4d5ab9bf0f32c781ccb208da3c95818018)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix unchanged assignments being dropped if other lines changed
* Fix not passing variable name from single-line assignments to the
function
* Fix not trimming the trailing quote from values
(Bitbake rev: 0b0c82f49cf2de887967d305768cbd95314bb171)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In certain contexts it can be useful to find the layer that a file (e.g.
a recipe) appears in.
Implements [YOCTO #7723].
(Bitbake rev: 3bf9c8830c5d5eea5502230d5af84ebd87ad5849)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some very basic safeguard against recursively deleting paths such
as / and /home in the event of bugs or user mistakes.
Addresses [YOCTO #7620].
(Bitbake rev: 56cddeb9e1e4d249f84ccd6ef65db245636e38ea)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had versioned dependency support in LAYERDEPENDS for quite a long
time, but I can say with pretty good certainty that almost nobody has
used it up to now because it was too strict - the specified version had
to exactly match the version in your configuration or you would get an
error; there was no "greater than or equal" option, which is usually
what you will want given that LAYERVERSION does get bumped from time to
time.
However, users mismatching layer branches and then having their builds
fail later on with some incomprehensible error is still a pretty common
problem. We can't simply use the git branch because not everyone is
always on a branch and the branch names don't always match up (and
that's not an issue). To provide a practical means to address branch
mismatching, I have reworked LAYERDEPENDS version specifications to use
the more familiar "dependency (>= version)" syntax as used with package
dependencies, support non-integer versions, and clarified the error
message a little. If we then take care to bump the version on every
breaking change, it is at least possible to have layers depend on these
changes when they update to match; we can now even support a major.minor
scheme to allow retrospectively adding a version limiter to old branches
when a new branch is created and yet still allow the old branch minor
version to be bumped if needed.
Fixes [YOCTO #5991].
(Bitbake rev: 408be9cdf2b1e32e64ea488d8051a546fb54c144)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We really want an error rather than the version to just be silently
skipped when the operator is missing (e.g. "somepackage (1.0)" was
specified instead of "somepackage (>= 1.0)".)
(Bitbake rev: b6dc946f477adc40d68da16e2f2580cb3b4a10db)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a little crude as the usage basically ignores that you're doing
an append operation, but for a lot of cases it will be sufficient.
(Bitbake rev: 24a28205ab680b6cc645d97b76c9855920608229)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix add-layer error message when a layer is already in BBLAYERS
* Ensure we show an error message if we can't find BBLAYERS at all
(Bitbake rev: 1c743fd2103730e27699dd55efc6914d3b0c3702)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add a generic edit_metadata_file() function to modify variable
assignments in any metadata file (conf, bb, bbappend) using a callback
for flexibility
* Add a specific edit_bblayers_conf() function to modify
conf/bblayers.conf and add and/or remove layers from the BBLAYERS
value within it.
(Bitbake rev: aa03a28b442549dd8ffe92ae4d6390f62202a76a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a function that allows executing a flat python function (defined
with def funcname(args): ...).
(Bitbake rev: 20e6939ebcb62e08a9a7ad586a915dfe368136a0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This stream redirection of stdout is horrible. pstats takes a stream argument
so lets use that instead.
(Bitbake rev: 93d155f4766e27e7b004d13569aa03961fe89e3b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our usage of multitprocessing is problematic. In particular, there is a bug
in python 2.7 multiprocessing where signals are not handled until command
completion instead of immediately.
This adds a workaround into our wrapper function to deal with the issue.
(Bitbake rev: a16185e602b39b71475aa7e9ee80ad2b1f28d0f7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"set1 in set2" doesn't do what you'd expect, and if it did do a subset test
that's not the logic required by contains_any().
Instead get the intersection of checkvalues and val and check if the resulting
set is empty or not (by evaluating it in a boolean context), which tells us if
there are any elements in common.
Based on a patch by Valentin Popa <valentin.popa@intel.com>.
(Bitbake rev: 2e742c03e8dfdfa67899e7f5d579ed14bd87e139)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Checking for explicit exception names is bad, we also want to be able top
rely on inheritance. Fix these checks to be part of the real except clauses
so SkipPackage is recognised as being inherited from SkipRecipe.
(Bitbake rev: b131229145e1f2c372d6230a7b554e436c13c3f9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the depths of time we were rather confused about naming. bb files
are recipes, the event to skip parsing them should be SkipRecipe,
not SkipPackage. This changes bitbake to use the better name but
leaves the other around for now. We can therefore start removing
references to it from the metadata.
(Bitbake rev: 98d9e6e0f514a7cb7da1d99bf4bd5602b89426d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If an ExpansionError occurs during better_exec() we should just raise it
instead of printing the traceback, so that recipe errors (such as broken
URLs in SRC_URI) are more easily comprehensible.
(Bitbake rev: 5b0da8932c318813138c113d2bb20498145dbd42)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This includes contains_any in the special handling code for sstate. It
does not take into account the equivalence of the values. In current
code, considering 'bb.utils.contains_any("A", "foo bar", ...)':
A = "foo"
A = "bar"
A = "foo bar"
All those will get different signatures.
(Bitbake rev: d1e3345d715e488ec3f5515fb0e1fb39366346bc)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently bitbake only adds files to its dependency list if they exist.
If you add 'include foo.inc' to your recipe and the file doesn't exist,
then later you add the file, the cache will not be invalidated.
This leads to another bug which is that if files don't exist and then
you add them and they should be found first due to BBPATH, again the
cache won't invalidate.
This patch adds in tracking of files we check for the existence of so
that if they are added later, the cache correctly invalidates. This
necessitated a new version of bb.utils.which which returns a list of
files tested for.
The patch also adds in checks for duplicate file includes and for now
prints a warning about this. That will likely become a fatal error at
some point since its never usually desired to include a file twice.
The same issue is also fixed for class inheritance. Now when a class
is added which would be found in the usual search path, it will cause
the cache to be invalidated.
Unfortunately this is old code in bitbake and the patch isn't the
neatest since we have to work within that framework.
[YOCTO #5611]
[YOCTO #4425]
(Bitbake rev: 78d285871e4b8c54ccc4602d571e85f922e37ccd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A BBHandledException means we already showed an error to the user so
we shouldn't show a stack trace as this just confuses things further.
(Bitbake rev: 8a8bafc8ded98364a31878b23c64503a53affcd1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
print disappears into the ether, so use logger.warn and clean up the messages.
(Bitbake rev: 90f91f7402ff69f3fe9fba5f94a53d371303ce34)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BB_PRESERVE_ENV wasn't working since data.inheritFromOS wasn't getting a
correct list of keys to import into the data store. This fixes
things so it does add all environment variables into the data store
when BB_PRESERVE_ENV is used.
(Bitbake rev: 843e9339c5ee3c99657a40a0e2c7dbd777b6ef06)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Interestingly the previous version comparision was broken and we were always using
the compatibility code, masking this bug. Oops.
(Bitbake rev: d48e8bcb24e8fa5d4fd60fd2c9927a95976d8d8b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we've moved to require python 2.7.3, we can jettison the compatibility
workarounds/hacks for older python versions.
(Bitbake rev: a51c402304f2080a76720f9b31d6dfdbed393bba)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current execution context management for bitbake is ugly and the
use of a global variable is nasty. Fixing that is hard, however we
can improve things to start to establish an API for accessing
and changing that context.
This patch also adds in an explicit reset of the context when we reparse
the configuration data which starts to improve the lifecycle of the data
in setups like hob.
(Bitbake rev: 6c3281a140125337fc75783973485e16785d05a1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move various random imports to the start of the modules as cleanup
and avoid an import issue with bb.process on python 2.6.
(Bitbake rev: aed4adfbe3a591ca4f8e41fb763c9f961bf2e6d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3 is stricter about how files are accessed. Specficially:
* Use open(), not file()
* Use binary mode for binary files (when checksumming)
* Use with statements to ensure files get closed
* Add missing file close statements
(Bitbake rev: 9f08b901375ba640f47596f1bcf43f98a931550f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to the better_exec improvements, improve the compile failure
messages to be more user readable.
(Bitbake rev: 9bc92d0210e13e4cc98727f6c9ec2f47c2221e77)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current bitbake tracebacks are hard to read/confusing and sometimes
incomplete. This patch attempts to do better by:
* Moving the note about the exact exception to the end to make things
read in sequence
* Merged the initial stack trace to become part of the code dump
* Added handling for "/xxxx" file paths since we can load these files
and include the data as part of the trace
* Dropped the ERROR: prefix to every line, allowing the error messages to
be spacially accosicated in the UIs
* Moved the "From:" line to the top of each code block and ensured its present
consistently
With the complexity now in this funciton, I've added try/except wrapping around
it to ensure we catch exceptions in the exception handler too.
Example before:
"""
ERROR: Error executing a python function in /media/build1/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb:
TypeError: 'filter' object is not subscriptable
ERROR: The stack trace of python calls that resulted in this exception/failure was:
ERROR: File "do_populate_lic", line 13, in <module>
ERROR:
ERROR: File "do_populate_lic", line 6, in do_populate_lic
ERROR:
ERROR: File "license.bbclass", line 99, in find_license_files
ERROR:
ERROR: File "/media/build1/poky/meta/lib/oe/license.py", line 38, in visit_string
ERROR: if pos > 0 and license_pattern.match(elements[pos-1]):
ERROR:
ERROR: The code that was being executed was:
ERROR: 0009: destdir = os.path.join(d.getVar('LICSSTATEDIR', True), d.getVar('PN', True))
ERROR: 0010: copy_license_files(lic_files_paths, destdir)
ERROR: 0011:
ERROR: 0012:
ERROR: *** 0013:do_populate_lic(d)
ERROR: 0014:
ERROR: [From file: 'do_populate_lic', lineno: 13, function: <module>]
ERROR: 0002:def do_populate_lic(d):
ERROR: 0003: """
ERROR: 0004: Populate LICENSE_DIRECTORY with licenses.
ERROR: 0005: """
ERROR: *** 0006: lic_files_paths = find_license_files(d)
ERROR: 0007:
ERROR: 0008: # The base directory we wrangle licenses to
ERROR: 0009: destdir = os.path.join(d.getVar('LICSSTATEDIR', True), d.getVar('PN', True))
ERROR: 0010: copy_license_files(lic_files_paths, destdir)
ERROR: [From file: 'do_populate_lic', lineno: 6, function: do_populate_lic]
ERROR: 0095: lic_files_paths.append((os.path.basename(path), srclicfile))
ERROR: 0096:
ERROR: 0097: v = FindVisitor()
ERROR: 0098: try:
ERROR: *** 0099: v.visit_string(license_types)
ERROR: 0100: except oe.license.InvalidLicense as exc:
ERROR: 0101: bb.fatal('%s: %s' % (d.getVar('PF', True), exc))
ERROR: 0102: except SyntaxError:
ERROR: 0103: bb.warn("%s: Failed to parse it's LICENSE field." % (d.getVar('PF', True)))
ERROR: [From file: 'license.bbclass', lineno: 99, function: find_license_files]
ERROR: Function failed: do_populate_lic
ERROR: Logfile of failure stored in: /media/build1/poky/build/tmp/work/i586-poky-linux/eglibc-initial/2.17-r3/temp/log.do_populate_lic.17442
"""
Example after:
"""
ERROR: Error executing a python function in /media/build1/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb:
The stack trace of python calls that resulted in this exception/failure was:
File: 'do_populate_lic', lineno: 13, function: <module>
0009: destdir = os.path.join(d.getVar('LICSSTATEDIR', True), d.getVar('PN', True))
0010: copy_license_files(lic_files_paths, destdir)
0011:
0012:
*** 0013:do_populate_lic(d)
0014:
File: 'do_populate_lic', lineno: 6, function: do_populate_lic
0002:def do_populate_lic(d):
0003: """
0004: Populate LICENSE_DIRECTORY with licenses.
0005: """
*** 0006: lic_files_paths = find_license_files(d)
0007:
0008: # The base directory we wrangle licenses to
0009: destdir = os.path.join(d.getVar('LICSSTATEDIR', True), d.getVar('PN', True))
0010: copy_license_files(lic_files_paths, destdir)
File: 'license.bbclass', lineno: 99, function: find_license_files
0095: lic_files_paths.append((os.path.basename(path), srclicfile))
0096:
0097: v = FindVisitor()
0098: try:
*** 0099: v.visit_string(license_types)
0100: except oe.license.InvalidLicense as exc:
0101: bb.fatal('%s: %s' % (d.getVar('PF', True), exc))
0102: except SyntaxError:
0103: bb.warn("%s: Failed to parse it's LICENSE field." % (d.getVar('PF', True)))
File: '/media/build1/poky/meta/lib/oe/license.py', lineno: 38, function: visit_string
0034: new_elements = []
0035: elements = filter(lambda x: x.strip(), license_operator.split(licensestr))
0036: for pos, element in enumerate(elements):
0037: if license_pattern.match(element):
*** 0038: if pos > 0 and license_pattern.match(elements[pos-1]):
0039: new_elements.append('&')
0040: element = '"' + element + '"'
0041: elif not license_operator.match(element):
0042: raise InvalidLicense(element)
Exception: TypeError: 'filter' object is not subscriptable
ERROR: Function failed: do_populate_lic
ERROR: Logfile of failure stored in: /media/build1/poky/build/tmp/work/i586-poky-linux/eglibc-initial/2.17-r3/temp/log.do_populate_lic.3275
ERROR: Task 9 (/media/build1/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb, do_populate_lic) failed with exit code '1
"""
(Bitbake rev: c5de66b870406d9bd1161a9b7e2b04fe6eb065fe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The BB_ENV_WHITELIST doesn't work well and flushes BB_ENV_EXTRAWHITE,
here is an example:
$ export BB_ENV_WHITELIST
$ export BB_NUMBER_THREADS=10 (or other value)
Edit conf/local.conf, change "BB_NUMBER_THREADS =" to "BB_NUMBER_THREADS ?="
$ bitbake -e | grep '^BB_NUMBER_THREADS ='
we will notice that BB_NUMBER_THREADS' value doesn't change, though
BB_NUMBER_THREADS in both BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE.
This is because the "approved" inside the function approved_variables
doesn't include BB_ENV_WHITELIST or BB_ENV_EXTRAWHITE when
BB_ENV_WHITELIST is set (they are incuded by preserved_envvars()), so
the BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE will be removed from the env
in the first call from bin/bitbake, and when it is called again by
cooker.py, their value will be None, then the vars inside them will be
removed from the env.
Add BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE to the "approved" would fix
the problem.
[YOCTO #4031]
(Bitbake rev: d2b07e6516dd308d0045a7fdb72b588af9d676ad)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the remove function to better handle cases where path contains
special shell chars like whitespaces, '$', ';' or'\'.
Thanks to Enrico Scholz for the fix.
(Bitbake rev: 617511c9f86cc4ef52457653c8adff582d94bce3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst shutils.rmtree() is pythonic, its also slow. Its faster to
use rm -rf which makes optimial use of the right syscalls.
(Bitbake rev: 96088ebdec08e49ba9e8dbcac437bfcdc21f5983)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to empty out the environment whilst we build the cooker but
we need the environment for the UIs since hob uses DISPLAY and other
session variables.
This patch adapts the utils functions to return removed environment
components so we can reinject them for use by the UI, allowing hob
to work again.
(Bitbake rev: fc330d810099c57fefd4e706159a73ad8401d97c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Maintining hardcoded lists of user environmental variables is hacky,
replace these with the savedenv datastore. Allow access to that
through the BB_ORIGENV variable.
(Bitbake rev: 0a99563a4ea270594fd9a61da46f9387fb79dc66)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python 2.7 shows hangs with issues in its pool implmenetation. Rather than
try and hack around these, add a copy of the working pool implementation
to the compat module from 2.7.3.
(Bitbake rev: c9eb742637131e8dbd526d2ad9b458abea0a2d87)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Paul Eggleton
Markus Lehtonen
Benjamin Esquivel
Oscar Utbult
Robert P. J. Day
Ross Burton
Otavio Salvador
Robert Yang