| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
(Bitbake rev: ef2bf63e56b87e19d1a9059dd2d81a9a1a537254)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Ensure there is default command available if FETCHCMD_p4 isn't set.
Also clean up the getVar references whilst here.
(Bitbake rev: d150226d11d5f041f78c8c3ce4abc5465dbc81d8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file inheritance logging has been here since the dawn of time. It
duplicates output many times over and logs to debug level 2. When running
with the debug option, its understandable the user may want to see the
paths of files included in the build.
These changes remove pointless/duplicate output and print the
include paths clearly at debug level one in a form which
users should be able to more easily parse.
(Bitbake rev: 633a56987df639295fe9128418da5634050063e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a user runs with the -v or -D options, its understandable they'd
expect to see log output from the workers yet right now a bug in the
log handling does not show this.
Fix the conditional to ensure such log output is shown on the terminal
when it has been requested. Ideally this data should always flow to
the logfiles but that is for another patch.
This also fixes the code to do what was always intended in the comments,
i.e. if the user specifies -D or -v, output is shown from the tasks,
otherwise notes are suppressed.
(Bitbake rev: 20a3c93d8572969e76563f29bff89400b93ffae7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was reported that bitbake -D made no mention of which append files it
was using. bitbake -DD does but it makes sense to increase the log level
of this piece of debug information.
[YOCTO #6262]
(Bitbake rev: 5824bf9c6feea05567d155911f4ab2e371911d34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
specified in url
(Bitbake rev: 9a328262e047562a6edf7b2ec7b8a1949e287cbe)
Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(Bitbake rev: 42b7be1a6c5ff559f4a213eed04b370ca955460d)
Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
those with '_' in the name
Unfortunately we've been neglecting to pay the correct tributes to the
cookie monster and hence the datastore is malfunctioning.
Currently tributes are only paid on the last part of a variable after
the last "_" character. We need to split by *all* "_" characters since
an override may contain the character.
This fixes the code so the correct number of tributes are made. Paradoxically
parsing appears to be faster after this change.
(Bitbake rev: d1c712fd3a59fa804e6fd451612c30487671f3a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the power were to fail, it doesn't matter to us much if the data
makes it to disk or not, we'd have other problems. However an fsync()
call on a multi build autobuilder is painful so lets avoid them.
This is particularly true in this case if a timeout causes a reconnect
during a build.
(Bitbake rev: ec28256ac2a30f047585e8f61200d764bc295ded)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if you do localdata.getVar, the code parser simply ignores
the references. Change the code to use endswith() to catch more of the
references. These names are probably unique enough to get away with this.
Bump the cache version to ensure things get updated.
(Bitbake rev: cf763cddc3faa2361b4c4dbd08419e4ebabf208f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: c40a4100ddb841d231360344616e59ab98e61fb5)
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Doing so was causing leakage between the execs of the main value and that of
the subshell value, and was causing the cached subshell value to be used for
the overall variable. At the least this could cause execs contamination
between two variables that while differing, run the same subshell. Beyond
that, it's possible we could have been using an incomplete cached value of
a subshell for that of the main value.
Before this, bb_codeparser.dat would change between parses with differing
bbfile parse order. After, it does not change.
The codeparser cache version is bumped, to ensure we don't use potentially
incorrect cached values from previous runs.
This should hopefully resolve the difficult-to-reproduce issues we've seen at
Mentor Graphics where bitbake emits a script to run a task and misses
dependent functions, resulting in 'command not found' failures. This issue has
also been mentioned on the oe devel list, where someone hit a case where
oe_runmake was missing from a do_install task (IIRC). Adding debug information
showed that bitbake's information about the variable dependencies for this
task is inaccurate in the failure cases.
(Bitbake rev: 97537e4786a1e3a329249497498b59b8f5174fc3)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial version of this patch was reverted in
0a94e568152de550dedc8135a766beb18bf064ab
However, it was later agreed upon that it was reverted due to
a misunderstanding during code review; the patch is ok.
This version of the patch also removes an unneeded initialization of
the 'checksum' variable outside the scopes it is being used in.
(Bitbake rev: 9ee19a3ca2f8e11a91f0289ea3486310c61d40f2)
Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following up a previous patch for mercurial fetcher, I just fixed a
problem when calling update on a repository with subrepositories enabled.
Attached a patch that fixes this problem
>From caae519a2bd64bf7c729bb26aff344827def47fb Mon Sep 17 00:00:00 2001
From: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Date: Tue, 29 Apr 2014 15:29:47 +0200
Subject: [PATCH] bitbake: - fixed authentication issues in case of using sub
repositories
(Bitbake rev: dfa041c940caad12da50126a559afc8de089eeda)
Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
This reverts commit 6dfb33fd7204e09815bde7ba5bf21941a73fe965.
It causes an unindeded change in behaviour.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup the fix done in f9416e76e272ba3249abff099f6f3a47fe82e03e.
Instead of adding continue statements we can just move the last
statements into the final else-clause.
(Bitbake rev: 6dfb33fd7204e09815bde7ba5bf21941a73fe965)
Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only ever clone other repositories, if there were a problem such as power
failure, we'd blow away data and rebuild. As such we don't need fsync(). With
filesystems like ext*, the fsync pushes nearly all the data out to disk
which impacts all running processes.
We therefore set a configuration parameter to disable the fsync() calls.
Also fixup a case where basecmd wasn't being used for no good reason.
(Bitbake rev: 0a26abaf3a1e34d556c9375068dd17c879568d0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimisation where only the data we're interested in was finalised
was good but it turns out we can do better. In the case where a
class-extension is to be targeted, we can skip the other targets.
This change does that and speeds up parsing at the bitbake-worker
execution time. Specifically, you can see an improvement in the speed
of bitbake X -n.
(Bitbake rev: b56918c7ef7913e84356c69ee9b269844a446728)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
In dry run mode, stamps for noexec tasks are being written out which
is incorrect. Avoid this.
(Bitbake rev: aa6448a0552ba2947ac262b8b5314a593d1058d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When looking at a list of tasks, do_patch and do_unpack were being
given equal priority when one clearly depends on another. The
reason for this was the default task weights of 0 being to tasks.
This is therefore changed to 1 to allow correct weighting of dependencies
which means the scheduler has better information available to it about
tasks.
Weight endpoints differently (10) for clearer debugging of priorities.
(Bitbake rev: 12dc1d17fac3e8ec420fcafb06186d32fd847d89)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The zero priority task should be run first but was being confused with
the None value the priority field defaulted to. Check for None
explicitly to avoid this error.
In the real world this doesn't change much but it confused the debug
output from the schedulers.
(Bitbake rev: 49c9d8c9400f74c804c2f36462639236e0841ff0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: bb4980c63db386ce7d30d9a6b86e9f3861b3bc3a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: a8a32de0fb74ff63e5490e3b5e4419146a8f7367)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Since we now get wildcards in the file checksum list in the cache, we
need to ignore them when checking to see if they still exist. This
fixes connman-gnome reparsing on every bitbake execution in OE-Core.
(Bitbake rev: 340c250fc664414ab2715a454bedbd19e8efe103)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some explicit tests for unpacking local files to the appropriate
location. Some of these tests are actually testing for broken behaviour;
these have been called out in the comments, and associated bugs have
been filed.
(Bitbake rev: ca921c773c52392a5a338b2f493ad38c8132f708)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the recent change to split the log output to stdout and stderr,
error messages that appeared while the footer was printed got all
messed up. This was because the messages to stderr was output _after_
the footer, then clearFooter() tried to remove the footer but removed
the error message and parts of the footer.
(Bitbake rev: 4fafea4fa69542b491e84463f6eae0d5bf645673)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
If there is a directory matching a wildcard in SRC_URI when getting file
checksums, we should recurse into that instead of producing an error.
(Bitbake rev: ae87b7eb414e3d5eefd2effec7b30c22d2186b02)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Local fetcher's localpath is returning the parent directory for a
wildcard match; we need to handle this and add the wildcard
specification so that we checksum the correct files.
Fixes [YOCTO #6127].
(Bitbake rev: 4a90edd62c16cbf41b5b93280e155077564c774a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The path for "recipes/images/" was not added in BBFILES when Hob had
to search for an image recipe. Therefore, it could not find it and an
error occurred.
This path needs to be added when Hob is launched.
[HOB #6086]
(Bitbake rev: 35c67281775b08925957c32663d587d486944e0e)
Signed-off-by: Irina Patru <irina.patru@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if a file listed in SRC_URI was missing at the time of
parsing, and then was added and bitbake run again, it would not be
picked up because the recipe was cached without it. If we allow the file
to be added to the list of files to checksum, then it will be checked
for and found on the second run.
Fixes [YOCTO #4790].
(Bitbake rev: 71da822762cb298261cccdfa54b9c0fea02c3c5d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For a while its been puzzling me why connman-gnome rebuilds as often as it
does. It turns out you can trigger this with a new checkout of the metadata.
The SRC_URI that is causing the problems is:
SRC_URI = "file://images/*"
and rather oddly the results in checksums for a file "." being added to
the tree, e.g.:
('.', 'ab48a68186f0e0f277c21ef4cb390b4b')
The problem is that when iterating files lists, the checksum variable can
become set yet we don't break the out from the for loop, which leads to
odd (and non-deterministic) entries being added into the file checksum list.
The exact item added probably depends on the order of items on the disk.
Before this change, bitbake-diffsigs on connman-gnome:do_fetch would report:
This task depends on the checksums of files: [
('connman-signal-03.png', 'f6c16aee57b37b73793a2f1dea433ffa'),
('connman-signal-02.png', 'ad0cd22710c097d8174121fc1023c3be'),
('connman-signal-01.png', '8842bd83d2fa9ba56480df34c727c629'),
('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'),
('connman-signal-05.png', '808589e7e8d502b44c7b007e9e68d48c'),
('connman-signal-04.png', 'ab48a68186f0e0f277c21ef4cb390b4b'),
('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'),
('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'),
('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'),
('.', 'ab48a68186f0e0f277c21ef4cb390b4b')]
Afterwards:
This task depends on the checksums of files: [
('connman-signal-03.png', 'f6c16aee57b37b73793a2f1dea433ffa'),
('connman-signal-02.png', 'ad0cd22710c097d8174121fc1023c3be'),
('connman-signal-01.png', '8842bd83d2fa9ba56480df34c727c629'),
('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'),
('connman-signal-05.png', '808589e7e8d502b44c7b007e9e68d48c'),
('connman-signal-04.png', 'ab48a68186f0e0f277c21ef4cb390b4b'),
('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'),
('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'),
('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85')]
which is correct and deterministic without the "." entry.
(Bitbake rev: f9416e76e272ba3249abff099f6f3a47fe82e03e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some warnings and errors may come from a non-build context,
and they were not saved, even if they were counted for the current
build.
This patch saves these messages in memory until we have the
entire build context available.
[YOCTO #5642]
(Bitbake rev: fc7a74e7961775b5d7ff25298abed10138d24dc9)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
We rename a local variable in as to prevent a conflict with
a similary named function parameter.
(Bitbake rev: f4e57f794651c4894600445e843ca9d5e104cd84)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This solves a problem of custom images which inherit a base
image with IMAGE_BASENAME overwritten in their recipe by a
different value than its default one: ${PN}.
The value of IMAGE_BASE causes a crash when hob will try to
create symbolic links to the resulting images from the deploy
directory, because it will look for names similar to
<original_recipe_name>-edited-timestamp-machine.rootfs.*
which might be different from the actual resulting image.
The solution is to simply overwrite IMAGE_BASENAME in the
custom recipe to the default value in the case IMAGE_BASENAME
is found in the base recipe.
Some recipes which were affected by this problem are those
from meta-fsl-demos (e.g.: fsl-image-test).
[YOCTO #6017]
(Bitbake rev: e42ee93519000f827be49659b6b5fb7717b3d592)
Signed-off-by: Marius Avram <marius.avram@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a problem which happened when you tried to build an
image by selecting 'Start with an empty image recipe' from the
Image configuration page of hob.
The reason on of the bug was that the name of the resulting image
was threated the same way as ordinary custom images, when in fact
they should use the default name: "hob-image", because they do not
derive from any other recipe.
[YOCTO #6102]
(Bitbake rev: fa4ea3b4b40e7e9e6767e0cd51c6701e0af07135)
Signed-off-by: Marius Avram <marius.avram@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To find if a recipe is for an image, Hob checks if it inherits
image.bbclass. But when you add testimage in local.conf, this will
be added for each recipe, and it pass the test. Adding a "/" before
"image.bbclass", will check only for image.bbclass.
[YOCTO #6117]
(Bitbake rev: be8511c9d474c570f6ca7078e28919c8a5175a42)
Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you are using the testimage class then the old test mistook the
global inheritance of testimage.bbclass with the recipe inheriting
image.bbclass because it was only looking for that at the end of the
string.
Also tidy up the code so you an easily tell what it's doing. (The
original method may have been more "pythonic", but it does nothing for
readability.)
(Bitbake rev: b05e741cb5fe44b37538f2b727782f80dc9bb8fa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were not being collected properly because we were explicitly
excluding variables defined as functions from being stored in the
database. We don't want these to be shown in the variables list, and in
any case it makes sense for these to be stored elsewhere, so create a
separate model to store these.
Fixes [YOCTO #6050].
(Bitbake rev: 0d76a5461ce4bd554ff70a465064969e53edf0a4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes sure that the setFeatures command is marked
as read-only and that it can only run if the cooker is in
the initial state.
Additionally, remove logging from the XMLRPC module in favor
of sending the exception to the client for easy processing.
[YOCTO #6089]
(Bitbake rev: f0a1a3e24757f7658d272035620465f92a3e4c3c)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
[YOCTO #6051]
(Bitbake rev: 6dd8133b06bbda5cce50de39123f429a6a3f772d)
Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
This is an update on the sstate file saving data.
It saves both found and missed sstate tasks.
(Bitbake rev: 60c577b1080219b795d3c8ab4e149e929cf9ce14)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first part of the sstate code checks en-mass whether given checksums
are available. The next part of the code then either triggers those
setscene tasks either running them or skipping them if they've been
covered by others.
The problems was that this second part would always skip a task if it
was unavailable in the first part, even if it would have otherwise been
covered by other tasks.
This mean the mere presence of an artefact (or lack of presence) could
cause a different build failure.
The issue reproduces if you run a build and populate an sstate feed, then
run a second build off that feed, then run a third build off the sstate
feed of the second build (which is reduced in size).
The fix is rather than immediately skipping tasks if the checksum is
unavailable, create a list of missing tasks, then, if that task cannot
be covered by others we can skip it later. The deferral makes the
behaviour the same even when the cache is "incomplete".
[YOCTO #6081]
(Bitbake rev: 5edb1a3e3f454ba6e65551174d86229db2f99636)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a setscene task has [depends], its possible they may still get executed out
of order. The issue is that the dependencies are set to set() for all tasks
involved. This patch adds back in explict dependencies within these chains
to avoid the setscene task failures.
[YOCTO #6069]
(Bitbake rev: 724c889eed3b03d3199810c185086d3973af826c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Rather than passing featureset around various places where the data doesn't
really belong, run a command at connection time to set the appropriate
features. This is similar to what the process server does.
(Bitbake rev: c3b5cc5691291c74dd315c4439c80e0e4b2b5c1d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the featureset didn't match the defaults, we'd pay the price of two
base configuration parses which showed up adversely in the performance
benchmarks. This also passes the feature set into the cooker creation so
in the common case we don't have to reset the server. This speeds up
both knotty and hob startup. If the featureset doesn't match, the system
will reset as before, this just streamlines the common case.
(Bitbake rev: 1249543c4dbf3edeac033d888497864cfc807a4e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the change to more optimal default featureset behaviour, a race was
exposed by hob where the code may try and change self.data before it
exists. This change avoids that.
When the datastore is created, the cooker configuration is used so
data tracking is correctly handled regardless.
(Bitbake rev: 9d8f7efbc39d64124936ccaeb3c47a112e595d78)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Its not immediately obvious to the user that a logfile exists for a failed setscene
task. Add code to knotty to display where that logfile is in those cases.
[YOCTO #6055]
(Bitbake rev: 0664fa15597785dd90cf205531a9801e6da6ba47)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using bitbake -e in scripts, it would be helpful if the error
output appeared on stderr, not stdout. This change enables that building
upon the new bb.msg filters.
[YOCTO #5274]
(Bitbake rev: ebb797fc5c37d729e3cc8b2dc7156287d385c13b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I can understand why some programs would want the progress on stderr so
that real output can be captured on stdout. This is confusing for bitbake
since we don't show a progress bar at all in non-interactive cases.
Therefore make sure the progress bar goes to stdout, not the stderr default.
(Bitbake rev: 0529aa9966df5c56b07affe865efce18852efe5a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|