Since shell scripts run with 'set -e' the final exit at the end of the
script can only be returning 0. However, for correctness and to follow
the original intention of the 'cleanup' commands, let's fix the typo
and return the success of the last shell function rather than the
success of unhooking the exit trap handler.
(Bitbake rev: bef724057f1ea81571dd3ac5a9cf862f818434b5)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recent change to connect through the shell logging functions had an
unexpected side-effect - bb.error() and bb.fatal() cause a flag to be
set internally such that BitBake's UI will not print the full task log
on failure; unfortunately we have in places within the OpenEmbedded
metadata called these shell logging functions under error situations
where we still want to see the full log (i.e., the message we're sending
doesn't include the full error). Thus, provide a mechanism to fatally
exit with an error but unset the flag, utilising the built-in python
logging functionality that allows extra values to be passed in the log
record.
(Bitbake rev: e561b997c55e8537d82aa1339adfff4505cc38b7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a fifo under ${T} for each running task that can be used by the
task to send events back to BitBake. The purpose of this is to allow
OpenEmbedded's logging.bbclass (which provides shell function
equivalents for bb.warn(), bb.note() etc.) to have those functions
trigger the appropriate events within BitBake so that messages are shown
through the BitBake UI rather than just in the task log; to do that we
just call the python functions.
Part of the fix for [YOCTO #5275].
(Bitbake rev: bae330a1f8a59a912eca71177b3c6ba7c92a2f38)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.
This patch was mostly made using the command:
sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`
(Bitbake rev: 659ef95c9b8aced3c4ded81c48bcc0fbde4d429f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduced build mtime cache structure. Reset it before the build
to prevent bitbake from crashing when build/tmp/stamps hierarchy
is removed.
[YOCTO: #7562]
(Bitbake rev: f8590547a198a78334debdf14bf40acb50c22ecc)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the output in the python task/function run files is rather
incomplete and effectively useless. This enhances the code to take
advantage of the bitbake's dependency tracking and extend the output to
include dependencies. This makes the files more usable for debugging
purposes. Since this only happens at python function execution time, the
overhead is minimal in the grand scheme of things.
(Bitbake rev: 02667e048c3e632f857c87177c0022eaf5481802)
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>
Right now shared work signature data is saved to the non-shared directory
which is confusing to everyone including bitbake. Whilst its messy,
extra the stampbase data instead, which ensures the sig data is written
to the correct location alongside its corresponding stamp file.
(Bitbake rev: 7ae1d4844d9d3a76f86ef32c5a794e51e334e588)
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>
The buildstats and toaster use separate time markers to measure the
duration of task execution. This causes a mismatch in the time
measured by buildstats class and the time measured in toaster.
The solution implemented here is to timestamp the creation of
every TaskBase event on the bitbake server side and calculate
the execution duration as the difference between creation time
of TaskSucceeded and TaskStarted events.
Based on an original patch by Marius Avram.
[YOCTO #5485]
(Bitbake rev: 7a08282c074c264f414cf7665dc873f51245072c)
Signed-off-by: Marius Avram <marius.avram@intel.com>
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we have something similar to:
LOCKFILES = "${TMPDIR}/my.lock"
LOCKFILES_qemuall = ""
do_task[lockfiles] += "${LOCKFILES}"
when expanded, lockfiles will be empty for qemu, resulting in
File "/home/stefans/yocto/poky/bitbake/lib/bb/utils.py", line 630, in mkdirhier
raise e
OSError: [Errno 2] No such file or directory: ''
This should filter out the empty expansions.
(Bitbake rev: 7813e1bfd08cd48871f8c03cae2810265590105d)
Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tasks whose names contain underscores (such as do_populate_sdk in OE)
when converted to a task override do not function properly. If we
replace underscores with hyphens we can still have a working override
for these tasks.
(Bitbake rev: cf90bd6b2a0ab7dce922bffb500d6a2ff2ff10e2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the shell trap code was created in exec_func_shell(). Split
the function so that we can create the code separately.
Also, some whitespaces were automatically deleted by my editor. Since
this is not necessarily a bad thing, leave these changes too.
(Bitbake rev: c712e622d20c61a07c9c172b60e9dc6beae14197)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The user manual said:
'cleandirs' - directories which should created before the task runs but should be empty
But it only removes the dir, doesn't create it
[YOCTO #5703]
(Bitbake rev: 0636797d75874ce4577f29011d69c56a4c6b9e89)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently its near impossible to control task addition/deletion from
metadata context. This adds stong add/deltask API to bb.build
which is traditionally where it resided. The rather broken
remove_tasks function was removed, it didn't appear to do anything
useful or have any users.
This allows us to clean up hacks currently in use in metadata and use
standard API for it instead.
(Bitbake rev: bf7138dd38fc1f8efca80891198e3422fef64093)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Back in the depths of time we did support task removal. In the pre
AST days it was nearly impossible to continue supporting it, it wasn't
used so it was dropped. With the modern codebase we can easily now support
deltask and it would be very useful within the metadata since it can
massively simplify dependency trees.
As an example, a core-image-sato had 47703 inter task dependencies before
this patch and a patch to native.bbclass, afterwards with the noexec tasks
deleted, we had 29883. Such a significant simplification is worthwhile
and justifies adding a deltask operation to the system.
(Bitbake rev: acecbde6fb70ff3c96deab3cdf819d8442e87ed4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the computed name of a directory contains an undefined variable
reference, bitbake dutifully creates a directory with a name that has
${...} in it. However, the actual task script created then tries to cd
to that directory, and the cd command fails, because no such directory
exists -- because the shell has helpfully removed the ${...} which did
not match any actual variables.
Since we want the name to be used exactly-as-is, add single quotes around
the name so this doesn't cause strange failures running tasks, which
allows us to progress past such failures and get to a point where they
can be diagnosed.
(Bitbake rev: 2809c2e6f2f35f9b08058950be896947ab5a0284)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake tasks may be of type 'python' or 'shell',
or they may not be executed at all, which is record
as task type 'noexec'.
In order to record proper task type, this patch:
* creates no exec task type as the default value in
the toaster model definition
* adds full task flags to the bb.build.TaskStarted event
in build.py
* if the task actually starts, the toaster ui will
record the type of the task as either 'python' or 'shell'
based on the task flags.
[YOCTO #5073]
[YOCTO #5075]
[YOCTO #5327]
(Bitbake rev: 6648c57e6d369fc009ea3a9fe939def5d2c67bf5)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On Linux its not possible for processes to regain a previous nice level after
it has changed. Its therefore not possible to have a core low priority and
then raise the priorities of individual tasks.
This variable allows us to do something like:
BB_TASK_NICE_LEVEL = "5"
BB_TASK_NICE_LEVEL_task-testimage = "0"
to give priority to specific tasks which the BB_NICE_LEVEL functionality
doesn't give us the option of.
(Bitbake rev: 94d82997220c6cfc7028f76719df028ba8254a5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds task identifying information for all
runQueue and sceneQueue events, and for bb.build.Task* events.
This will allow matching event to specific tasks in the UI
handlers processing these events.
Adds RunQueueData functions to get the task name and task
file for usage with the runQueue* events.
Adds taskfile and taskname properties to bb.build.TaskBase.
Adds taskfile and taskname properties to the *runQueue* events
(Bitbake rev: b4a5e4be50d871a80dbe0993117d73f5ad82e38f)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We add the path to the logfile for all Task events except TaskInvalid
so that we can trace back the logfile locations at some future point.
TaskInvalid doesn't ever have a logfile.
(Bitbake rev: 8344d84c609446f59f9619cc7ca0d693b7e2bbd6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using the basename of the .bb file is not unique, for example xxx-native
and xxx can overwrite each other. If this happens whilst running, you can
get odd backtraces as one file is parsed as another tries to write out
new data.
Avoid issues by using PN for the output filename instead.
(Bitbake rev: c9534f8e59d44b885334607ed90a3be2e492ec69)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'courtesy' symlink for log.do_xxx are quite useful when debugging, so
with this commit, we now get similar 'courtesy' symlink for run.do_xxx
scripts.
We only create symlink for tasks, not individual functions.
The symlink is create right before the actual runfile is created, indeed
we cannot create the symlink right after running the task since a failure
or execption can happen, in which case the symlink wouldn't be created,
and symlink are particularely useful when the task failed!
Another option would be create the symlink after the runfile is created,
and before the script is executed, but that means we need to duplicate the
code in case of Shell vs Python task.
(Bitbake rev: a672b39c5d529ba85d72eee8fef4c4273eaa5397)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running scripts with 'set -e' produces silent failures with no
diagnostic. Add an exit handler which produces diagnostics, including
details of what was running if the shell seems to be bash.
(Bitbake rev: e213e6a4c297a4f1c22eed15bd7b4cbc0e9eab4f)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Clean up a number of old style accesses to the datastore.
(Bitbake rev: d872fef2c38749c3c6f5d84344db3ec2f9f134ce)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, tasks like fetchall are slightly broken since if a recipe
has specific [depends] which occur after do_fetch and add items not listed
in DEPENDS and RDEPENDS, they are not caught by recrdeptask. We've gone
around in circles on this issue (e.g
http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/runqueue.py?id=5fa6036d49ed7befe6ad50ec95c61a50aec48195
) and in many cases the behaviour of recrdepends is correct but tasks like
fetchall need the other behaviour.
To address this we add a recideptask flag which can be used in conjuction
with the recrdeptask flag to specify which task to to the inspection upon.
This means entries like do_rootfs[depends] which have do_fetch tasks are
caught and run.
I'm not 100% happy with needing another flag but I don't see any rational
way to get the correct behaviour in all cases without it.
[YOCTO #4597]
(Bitbake rev: f8c9b292b02ce2c28741b74901205f5e5807ca87)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "see xxx for further information" is misleading since it is just
the same information. Clarify just to mention the that this is the location
of the logfile without any empty promise.
[YOCTO #4343]
(Bitbake rev: 7088c0e8553dd3c408b5bc06f8c34d5b72e9ea9a)
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>
The stamp cleaning process that occurs before writing out new stamps for
a task was deleting taint files as well. This resulted in tasks that
were forcibly re-executed using the -f or -C command line options to
have their previous output restored from shared state when called upon a
second time, because the taint value was no longer incorporated into the
task signature and thus it was reverting to its previous value. This
also affected the kernel menuconfig command in OE-Core.
Note that the taint file *is* still deleted when doing -c clean, which
is the desired behaviour.
Fixes [YOCTO #3919].
(Bitbake rev: e6db0ee31178d4386802e720d75303ec7dc21519)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe with no dependencies results in a traceback (e.g. all in
ASSUME_PROVIDED). This shouldn't happen and this patch fixes it.
(Bitbake rev: dee7decf87dfa8cb966fe40846d27f3e6ab1846b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Leaving the sigdata files around can aid debugging and doesn't harm
anything. This is the easiest way to allow this to happen.
(Bitbake rev: 1f500149ecd533a6edbeea902c3f1e009c755154)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "*" part of the mask is to ensure we clean both any stamp, and any
setscene varient. It turns out we would also trample other tasks,
e.g. do_package_write could trample do_package_write_rpm. do_package also
tramples do_package_write_* but this is less of an issue since the other
tasks depend on it.
Rather than use the wildcard, we can just use a list instead.
[YOCTO #3484]
(Bitbake rev: c14d831ea3f625e9a47266a0c4e6deefc924ca5a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently when we execute a task, we don't remove other potentially stale
stamps. This can mean if you switch between two different versions of a
recipe without a clean, the build can get very confused.
This patch adds in functionality to allow a wildcard expression of stamp
files to be removed when creating a new stamp file. This patch adds in
the core of the code to enable this but it also requires metadata support
to enable it.
When writing this improvement I went through several different options but
this was the only way I could find to allow things like noexec tasks to
function correctly (where stamps need to be created without the data store).
[YOCTO #2961]
(Bitbake rev: e026469b307522e5b6a680e0ae5587749d33dcae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit 2718537b4b (bitbake:
build.py: Only execute mkdirhier if stampdir doesn't exist) build
failes as cached_mtime_noerror needs an argument - stamp dir. This
argument was forgotten.
(Bitbake rev: e69103c4f7e45c24f1fbe9df0383f39e877abcb4)
Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I noticed this was showing up on profile logs as a sigificant time user
in "bitbake bash" when bash was already built. It reduces the time from
5.2 to 4.5 seconds in my test environment.
We make use of the parser's mtime cache as once a directory exists,
we can assume it continues to exist and this avoids syscalls.
(Bitbake rev: 769b694eeb617bb793bd79d0d7b29c43d2646ece)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two problems with the _logged_communicate that are both
caused as a result of buffering I/O issues:
1) log truncation when python fails
2) While a bitbake task is running it is impossible to see what is
going on if it is only writing a small incremental log that is
smaller than the buffer, or you get only a partial log, up until
the task exists. It is worse in the case that stderr and stdout
are separate file handles, because previous code blocks on the read
of stdout and then stderr, serially.
The right approach is simply to use select() to determine if there is
data available and also flush the log before exiting.
This is based on a patch from Jason Wessel <jason.wessel@windriver.com>
with some changes to flush upon exit, abstract the non blocking file
descriptor setup and drop the buffer size parameter.
(Bitbake rev: 361fb71e907aa84c28ecec79fefc6ca39c39172f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently its not possible to add arbitrary RDEPENDS to a specific task.
This can be useful and this patch adds functionality equivalent to the
'depends' task flag.
(Bitbake rev: db65080a6199baecc5c422294a4c4a9fd12dc29e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If -f is specified, force dependent tasks to be re-run next time. This
works by changing the force behaviour so that instead of deleting the
task's stamp, we write a "taint" file into the stamps directory, which
will alter the taskhash randomly and thus trigger the task to re-run
next time we evaluate whether or not that should be done as well as
influencing the taskhashes of any dependent tasks so that they are
similarly re-triggered. As a bonus because we write this file as
<stamp file name>.taskname.taint, the existing code which deletes the
stamp files in OE's do_clean will already handle removing it.
This means you can now do the following:
bitbake somepackage
[ change the source code in the package's WORKDIR ]
bitbake -c compile -f somepackage
bitbake somepackage
and the result will be that all of the tasks that depend on do_compile
(do_install, do_package, etc.) will be re-run in the last step.
Note that to operate in the manner described above you need full hashing
enabled (i.e. BB_SIGNATURE_HANDLER must be set to a signature handler
that inherits from BasicHash). If this is not the case, -f will just
delete the stamp for the specified task as it did before.
This fix is required for [YOCTO #2615] and [YOCTO #2256].
(Bitbake rev: f7b55a94226f9acd985f87946e26d01bd86a35bb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The format of the log file and run file are now selectable
using BB_LOGFMT and BB_RUNFMT, respectively.
The following values may be used:
{task} - task name
{taskfunc} - task.func or func, if task==func
{func} - function name, only available in BB_RUNFMT
{pid} - pid
The log/run files may be placed into a subdirectory that
is relative to T.
Default BB_LOGFMT is: log.{task}.{pid}
Default BB_RUNFMT is: run.{func}.{pid}
(Bitbake rev: 588da606eb81c52cb92d29041e1c67897427bfdf)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We now add a debug message when entering and exiting a python or
shell function. This makes it easier to inspect a log and figure
out the run order from the logs.
(Bitbake rev: a0f554d0e722b6705844c6031fdcafa5d1a1c8a7)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
exec_func_python and exec_func_shell are similar, but variable
usage has diverged sync the two up. Since exec_func_python is first
use that as the guide for the later exec_func_shell variable naming.
(Bitbake rev: ccfe1a3a2419172799957676107f240badf3f062)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new log.task_order contains an ordered list of the tasks as they
were executed in any given recipe. The format of the lines is
<task> <pid>: <log file>
(Bitbake rev: 8662b43dcbd6e38a5b2ab9d6529af1fb08c146bf)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using symlinks to absolute paths isn't gaining us anything, and can cause
problems in situations such as automated build systems when they try to
resolve the link, depending on the mechanism used to pull the build artifacts
(e.g. nfs).
(Bitbake rev: f9cf2671c0ecad153db11bca1aebe151213bfb42)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change for setscene events to fire a TaskFailedSilent event instead
of TaskFailed resulted in "FailedSilent" being reported in the task
finish note log entry, which is not really desirable, so change it back
to reporting "Failed" again.
(Bitbake rev: 224bc74d4e901b7886b845fbb3b5fe7564a2f6cb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable configuring whether "set +x" is added to all shell tasks rather
than forcing it; this is enabled by setting BB_VERBOSE_LOGS to 1.
(Bitbake rev: 659411b6bb30e1a8355afc1c29b8170a8f2b55ac)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* When a setscene task starts, print out that it's starting in the UI
(ensuring we get the correct task name)
* When a setscene task fails, ensure we remove it from the list of
running tasks so that if you break out any time afterwards it
is not still listed.
(Bitbake rev: e8a3499c95a6d4f2b8fed002fb9504733c5be3c6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andre McCurdy
Paul Eggleton
Richard Purdie
Ed Bartosh
Robert P. J. Day
Alexandru DAMIAN
Stefan Stanacar
Laurentiu Palcu
Robert Yang
Peter Seebach
Nicolas Dechesne
Andrei Gherzan
Mark Hatle
Christopher Larson