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: 35769412de6387f55e5efa4ebc59a8d1e3c8870f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Small tweak to ensure these items are printed into the log since there
is other logging code which looks for the header and this makes it clearer
the server did start but is slow somewhere in startup.
(Bitbake rev: 9b15f265643af8bd85af87164ee5cab0bf58ccbb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ${DL_DIR}/svn directory is used by BitBake to keep checked-out SVN
repositories from which tarballs are generated. These repositories were
protected from concurrent update with a lock on the tarballs. However,
the tarballs are specific to the SRCREV and module checked out (many
tarballs can come from the same repository), meaning a repository could
be modified concurrently if two recipes checked out two different
SRCREVs or modules from it in parallel. This caused errors like the
following:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '/home/foo/downloads/svn/repo/trunk' locked.
svn: E155004: '/home/foo/downloads/svn/repo/trunk' is already locked.
Fix it by adding a per-repository lock that's independent of the module
and SRCREV.
(Bitbake rev: cddd27fb66bf82465cf8eb5012cb8e3c088625a5)
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@bmw.de>
Signed-off-by: Michael Ho <Michael.Ho@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if there are no setscene tasks, the disk monitor isn't started.
Move the startup code to somewhere to ensure it always is started. This
issue would partially explain occasional selftest failures.
(Bitbake rev: 7e76237c930d354ee7eb37d247d71b4f4fbf7993)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also use assetIn instead of assertTrue which aids debugging failures.
(Bitbake rev: 7e9c0bffb95ca92cab61deeeef18f45f1b4edb6f)
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: 8bd519b04c7d6ee4cf626d5e04110c3759488d28)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
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: b0ad961064ef6ecd77fab3435e5652c4ae284426)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
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>
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>
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>
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>
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>
Currently when a variable is renamed, all the variable history is lost.
This makes it hard for users to understand/debug where values came from.
Improve the code so that history is preserved across renamed variables.
(Expanded variable key names are a special case of variable renaming)
(Bitbake rev: 11722c989077a8751a5d0653c523760bf91e6efa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The environment was being cleared before the UI imports occurred which
caused problems for graphical UIs like taskexp. The full environment was
intended to be available to UI clients and it was only meant to be cleared
for the server/cooker, so tweak the code order so this is the case.
This fixes problems reported for taskexp.
[YOCTO #12670]
(Bitbake rev: ac15028391fdcc3fec2dd0e64a4f763ce63e5449)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some repositories may specify a relative submodule path. If this happens,
it is our responsibility to use the parents URL (ud) and handle any relative
processing ourselves.
(Bitbake rev: fd9893c338df7828b2c01f1d548aa86dfcf7c50a)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new fetcher did not run 'git submodule update' recursively.
(Bitbake rev: 377ed943357b6d47d41d84edbf971741f44affa9)
Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new gitsm fetcher assumed that submodules were living directly in
the 'modules' directory, whereas they can be arbitrarily nested inside
subdirectories.
Solve it by first creating the parent of the destination directory for
the symlink and copy steps.
(Bitbake rev: 3dbc84e9c572f43209b79f3656d7dc35a6d982ba)
Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The method 'store_log_event' in 'buildinfohelper.py' always puts log
messages from CLI builds into the backlog but never takes them out.
The "close" method now forces all backlogged CLI events to be registered.
[YOCTO #12813]
(Bitbake rev: 6458cc4234337f551dfe189b6f8800d8da886c24)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The shallow_tarball check is never true due a check on the caller side.
The tarball check is not related to the code on the caller side.
(Bitbake rev: 086eddcf8c7520ff5c52ce2a11ca9bf5b5fe5d7e)
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>
To improve the readability we extract the different scenarios of why
the clonedir needs an update.
(Bitbake rev: 9038e029f4f0ab413727de76c74248cbb3cdc9ea)
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>
GitLab returns a redirect from /foo to /foo.git which older releases of Git
don't handle when cloning. These tests don't clone so the redirect works, but
let's be consistant with the structure of these URLs and add the .git suffix.
(Bitbake rev: d47febbae4ff24be259037f12bafbc14b9e2d6a8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The prior fetcher did not know how to work with MIRRORS, and did not
honor BB_NO_NETWORK and similar.
The new fetcher approach recursively calls 'gitsm' download on each
submodule detected. This ensures that it will go throug the
standard download process.
Each downloaded submodule is then 'attached' to the original download in
the 'modules' directory. This mimics the behavior of:
git submodule init
but there is no chance it will contact the network without permission.
It then corrects upstream reference URIs.
The unpack steps simply copies the items from the downloads to the destdir.
Once copied the submodules are connected and we then run:
git submodule update
According to the git documentation, git submodule init can and will modify
the project configuration and may connect to the network. Doing the
work manually prevents this. (This manual process is allowed based
on my reading of the documentation.)
See: https://git-scm.com/book/en/v2/Git-Tools-Submodules
The small change to the existing test is due to this new code always assuming
the code is from a remote system, and not a 'local' repository. If this
assumption proves to be incorrect -- code will need to be added to deal
with local repositories without an upstream URI.
(Bitbake rev: 9c6b39adf9781fa6745f48913a97c859fa37eb5b)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test case was changing the current directory, but was never restoring it
to the original location. This causes occasional failures in later test cases.
(Bitbake rev: 8c222c45148d1f21c2390d66ddd9d3e33b397f05)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A nasty corner case leads to a hang when utils.lockfile is called from
oe-core's package-manager:deploy_dir_lock (in turn called from
rootfs:_create further up the call stack) with "name" owned by root
and the user running bitbake has no write access.
Because this code runs under pseudo, the UID and EUID of the bitbake
worker process are 0, so the os.access(dirname, os.W_OK) returns True
i.e. it thinks the path is writable when in fact it's not writable.
Only later when trying to open the file an Exception it thrown because
the OS prohibits writing, but the Exception is ignored and the open is
retried leading to an infinite loop.
So this fix is to not ignore the "Permission Denied" exception.
An alternative fix would be to replace the os.access() call with an
try: open() except() at the beginning of the function.
(Bitbake rev: 0cb64d0f85b41b2fa764baf6ff7ea1b13f95004e)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
