Instead of not even having the test functions if network tests are disabled, use
a custom decorator to mark the network tests and skip them.
(Bitbake rev: cc420f430b1dafd9ca944bea259a564aaab34595)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you run bitbake in an invalid directory, the user experience
is poor:
birbake/lib/bb/main.py", line 427, in setup_bitbake
topdir, lock = lockBitbake()
File "./bitbake/lib/bb/main.py", line 494, in lockBitbake
lockfile = topdir + "/bitbake.lock"
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
This ensures we exit straight away with a better error message.
[YOCTO #12163]
(Bitbake rev: 562f9ee674a8b392437096422b9cceab9c3cba2e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Python 3.6, glob.glob() was reimplemented to use os.scandir() (which
itself appeared in Python 3.5), thus our monkey patching of os.listdir()
here was no longer effective. The end result was not only that bitbake
wouldn't notice added recipes or bbappends with BB_SERVER_TIMEOUT set
when being run with Python 3.6 (the shipped Python version on Fedora 26
and some other distribution versions), it also broke devtool modify,
devtool upgrade and devtool extract since they rely on the ability to
create a bbappend on the fly and have bitbake pick it up.
To fix it, do the same monkey patching for os.scandir(), which needs to
be conditional upon that actually existing since we have to support
Python 3.4 that doesn't have it. Long term we should probably look for a
better way to handle this that doesn't involve monkey patching Python
library code.
Fixes [YOCTO #12185].
(Bitbake rev: d02e90db32e7ee341c2ba3be79b0627d8796bdd6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The newly added file in the last commit was corrupted, fix it.
(Bitbake rev: be393f247a08c0a4a50a6a76b8fd57f78295d2a1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding layer "meta-signing-key" to conf/bblayers.conf
Traceback (most recent call last):
File "/local/build/project/build/poky/bitbake/bin/bitbake-layers",
line 103, in <module>
ret = main()
File "/local/build/project/build/poky/bitbake/bin/bitbake-layers",
line 96, in main
return args.func(args)
File
"/local/build/project/build/poky/bitbake/lib/bblayers/layerindex.py",
line 250, in do_layerindex_fetch
self.do_add_layer(localargs)
File
"/local/build/project/build/poky/bitbake/lib/bblayers/action.py", line
44, in do_add_layer
if not (args.force or notadded):
AttributeError: 'Namespace' object has no attribute 'force'
(Bitbake rev: 4325f7a7df67eaf4b51af03b453e84bf88fae408)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake server changed such that the Toaster custom settings from
'toaster.conf' and 'toaster-bblayers.conf' that were set when
the '--server-only' mode was started were lost when the subsequent build
request happened, resulting in builds missing all custom changes.
This patch asserts those environment settings in both server calls.
[YOCTO #12194]
(Bitbake rev: fa767d85f19a7af92a44fe11fdfb38633009ad71)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the destination is a directory, building the the destination file
path is always needed. That's because even if the copy fallback is
taken, it's always followed by a rename.
(Bitbake rev: 14c17480827ced2e03c1b62dc839696421fc4de8)
Signed-off-by: Alberto Mardegan <amardegan@luxoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were seeing cases where we could hit the 5s timeout on large/fast machines
running many different tasks at once. Increase this to 30s since the main
connection timeout path should no longer hit this slow path.
[YOCTO #12116]
(Bitbake rev: 131d4b8a5834781a93ed41e2967d8dcd4d80f29a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dot '.' character should be allowed in the user paths for
local non-git layers, DL_DIR, and SSTATE_DIR.
[YOCTO #10650]
(Bitbake rev: 9c0f6e81dae0b91b425e6c0cdf64caa5c15d92b5)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The HEAD reference in Toaster layers are reserved for the
"Local Yocto Project" layers, stored at the top directory.
Imported layers are not allowed to use this since they are
managed differently - for example the 'remotes' will collide.
Fix the add layer handler to not drop the data fields when it
is a git repo.
Explicitly inform the user when an internal Toaster error is
returned via AJAX, so that they know why clicking the layer add
button did not do anything.
[YOCTO #9924]
(Bitbake rev: 04bd9c9341e8390a7923fa0122cd4cb0befa569f)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In collect_bbfiles() we're monkey-patching os.listdir in order to find
which directories to watch, and then undoing that when we're finished -
however if an exception occurred for any reason there was nothing to
ensure the latter occurred. This may not have caused any issues, but as
this kind of thing really ought to be secured using try...finally just
in case, so do that.
(Bitbake rev: 013047484a03185c0ce281c53c1db4949cdc4e69)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code that was supposed to watch directories along BBFILES for
creation of new files wasn't working in the case where the directory did
not initially contain any matching files - since in updateCache() we are
passing the directory path to add_filewatch() and the latter function
calls os.path.dirname() on the path on the assumption that it is a file
path, and thus the parent of the directory got watched but not the
directory itself. (If the directory wasn't empty everything worked fine
since add_filewatch() was called elsewhere with the path to one of the
files in that directory, and thus the directory got watched). Add a
parameter to add_filewatch() to tell it we are passing it directory
path(s) rather than file path(s).
(Bitbake rev: 47a34dee08fcc25d896a1bdf16fa86267f0b898f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printing the last 10 lines of bitbake-cookerdaemon.log when the server
fails to start can sometimes result in printing the output from a
previous run, which could lead the user completely down the wrong path
in terms of the cause of the failure. Use a known start text containing
the time which we can then look for when scanning through the log, and
then grab the last 10 lines of that part instead.
Fixes [YOCTO #11903].
(Bitbake rev: 567f2cf1bc455b4f3cfb1cbd7f25145360b05a62)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The whitelist shouldn't have to be populated in order for the
enforcement to work properly - check if the list is not None in order to
determine whether the functionality is enabled or not since that is how
the function that sets up the list behaves.
(Bitbake rev: 7b1e79c352ca6eef1693d8abfacf7505544f1caa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issues in start are not being correctly detected by the current readypipe
code. Change it to use specific "ready" or "fail" messages to correctly
determine the correct failure mode and avoid bitbake seeming to hang
(it does currently timeout eventually).
[YOCTO #12062]
(Bitbake rev: 60d4791e3dd05729d2a2adf6f3b203c80d466a73)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the Toaster stable release selection to 'Rocko' and
the bitbake version to '1.36'.
[YOCTO #12037]
(Bitbake rev: ed3aab90dbf9b6efefd9eb66d81123cb94d3c7da)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Stop the pending build and report to the user if there is
an internal exception due to a git error, a bitbake server
error, or if the server-only mode halts due to for example
a user syntax error in a layer or recipe.
These exceptions were not caught because they occure before
the normal toastergui processing was started.
[YOCTO #12056]
(Bitbake rev: 2cd664097c29ad07b08c82d07a239ca199abbc9a)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there is a network failure the return value from latest_versionstring() is
('','') which later causes an exception when comparing versions.
Improve this by checking the return value and failing the test early.
[ YOCTO #12053 ]
(Bitbake rev: 3f034d2172bf64ecc43577b43e0cf032a54b1358)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since 2017-08-17 (git version 2.14.1.473.g3ec7d702a) using deprecated
git branch parameter "--set-upstream" causes a fetcher error. Replace
it by "--set-upstream-to".
https://git.kernel.org/pub/scm/git/git.git/commit/?id=52668846ea2d41ffbd87cda7cb8e492dea9f2c4d
says, it's deprecated since 2012-08-30 so hopefully all still supported
host distributions have new enough git to support "--set-upstream-to".
ERROR: PACKAGE do_unpack: Fetcher failure: ...;
git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master failed with exit code 128, output:
fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.
ERROR: PACKAGE do_unpack: Function failed: base_do_unpack
(Bitbake rev: 2ab50074c1a6c56a8a178755de108447d7b7acaf)
Signed-off-by: Andre Rosa <andre.rosa@lge.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the UI disconnects, we can throw away any server-side remote
datastores we created in response to calls from the UI, and we *must*
drop everything in extraconfigdata or it will taint any future
operations.
Dropping extraconfigdata upon disconnect fixes taskhash mismatch errors
when running devtool.DevtoolTests.test_devtool_update_recipe_local_files
within oe-selftest with BB_SERVER_TIMEOUT=100 in OpenEmbedded.
(Bitbake rev: 1ca2eec459424892391f060442ef38cf28d6a54a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have a layer with a blank BBFILE_PATTERN the layer was ignored
when processing the list of layers with priorities. This list is not
only used for processing recipes, but also by additional programs such
as bitbake-layers show-layers.
Without this change, a layer that provides configuration or classes
only does now show up in show-layers, which is used by the
yocto-compat-layer.py script. This causes a failures in the compatibility
check.
(Bitbake rev: a0eaf8c0f228f984bafff09e4e9739f758dc1a9b)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're implementing reset() in SignatureGenerator at all (and we need
to for a basic non-OE BitBake setup where that is the default signature
generator), then we need it to be clearing out the internal values
properly.
(Bitbake rev: 13f52d38fdbcb84c2a0c46f85baa44b22d53fdc1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The list of columns in the many 'Edit Columns' pop-ups became unsorted
with the 'Toaster Table' implementation. These entries need to be
gathered and sorted in the column processing.
[YOCTO #12004]
(Bitbake rev: 17aa1ef8f0a00dd3456aac199e558a2f96bf7ad9)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default layers are missing the recipe link definitions in
the fixture files, and because they are predefined they do not
get the updated information from the Layer Index.
[YOCTO #12006]
(Bitbake rev: 2ff5592baf011de9c778d3c2481b8ed3912f1a4b)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The file "lsupdates.py" is missing the import of 'ToasterSetting',
and that breaks setting up and updating Toaster and its database.
[YOCTO #12036]
(Bitbake rev: d4aef1f1f03d88acc76423b55d8bd6c137f66f44)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If no external layers are defined, pokydirname is not set. Rectify
this by taking the 'be.sourcedir' as the pokydirname.
[YOCTO #12015]
(Bitbake rev: 3b0f04c7b00aaf44ba146c432fcb5d6fd7dafcea)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the debug messages during build contains a list of all layers
but without spaces or other separators between them. Use pformat
instead.
[YOCTO #12014]
(Bitbake rev: 9fe38f94b54a8644ac6f493c49e63dd6da5bfbdf)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The build page provides tables related to performance that
cover build time, CPU time and disk IO. The "Edit columns"
drop down does not allow selection of the Order column and
makes it hidden as well which is not accurate from user
interaction point of view.
This patch enables the hideable property for the Order column
so it is hidden by default but the user can enable it through
the drop down if need be.
[YOCTO #11040]
(Bitbake rev: 1f1cc1edb21aeec684ef7323554794b33d84d414)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There must be at least one FSTYPE selected in the Toaster bitbake
variable editor page. When the user deselects all the "Save"
button gets disabled, but the error message is missing.
[YOCTO #8126]
(Bitbake rev: 193577655b7491126ca5fa91fa76d79329e900c2)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BB_SERVER_TIMEOUT=100 oe-selftest -r bblayers
was failing and highlighted that since parseConfiguation clears data
structures, it needs to also clear parsecache_valid as it no longer
contains correct data.
(Bitbake rev: 7234f33a7eb38ad51a8345f6689bc26e29f29f92)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't actually see how this was working, nothing connected the commandline option
to the data in TaskData(). Drop the remaining pieces of this option, it was a relic
from a decade ago and we want deterministic builds, not random tries until something
might work.
(Bitbake rev: 767c7ba8fc76ec667ac1567de1c971c3575f2ecd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix failure after commit "cooker/siggen: Reset siggen when reparsing"
(e4c6ca9440f63761560b49bbe12654441f54687e) when executing without
specifying a BB_SIGNATURE_HANDLER.
(Bitbake rev: 2a78c2d09aea0323632bbc927f370f1d3c9c249e)
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BB_SERVER_TIMEOUT=100 oe-selftest -r devtool.DevtoolTests.test_devtool_build_image
fails, the reason is that internally, the limited_deps flag is set in
the bitbake server and then never cleared. This causes the sysroots to
be setup incorrectly (as per the limited dependency case) and builds
break. There is also potential for corruption of recipecaches.
Add shutdown/cleanup code to ensure these effects don't 'stick'.
This bug is particularly nasty as you can destroy TMPDIR with large
sysroots in build work directories which are prone to break.
Also ensure mtime cache is cleared (to match buildTargets) and
that no lasting changes are made to siggen either which ensures:
BB_SERVER_TIMEOUT=100 oe-selftest -r devtool.DevtoolTests.test_devtool_upgrade_git devtool.DevtoolTests.test_devtool_virtual_kernel_modify
works.
(Bitbake rev: 0a7ee8c8378bba9877c260b1aee782878f1935b4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When fetching source for the first time within scripts such as
OpenEmbedded's recipetool, we don't want to be showing warnings about
NPM_SHRINKWRAP or NPM_LOCKDOWN not being set since there's no way we
could have set them in advance. Previously we were using
ud.ignore_checksums to suppress these but since we are now using a more
standard task-based path to fetch the source, we need to disable these
through the metadata. Look for a "noverify" parameter set on the npm URL
and skip the checks if it is set to "1".
(Bitbake rev: 8c4b35d1e4d31bae9fddd129d5ba230acb72c3bb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you run some other operations that result in the cache being
populated, and then call buildFileInternal(), then you can end up in a
situation where the cache already contains information about the recipe.
For example in OE this can now happen when you use devtool upgrade.
Normally this doesn't cause any problems, unless you have a non-absolute
path in BBLAYERS - in buildFileInternal() we are calling matchfile() which
will convert the filename to absolute, but later when taskdata goes to find
the providers of the recipe it finds the non-absolute path, sets up the
task information using this and then the runqueue can't find any tasks
matching the absolute path. To fix this, back out the optimisation I did
earlier in bitbake rev ba53e067a2d448dd63b4ca252557ce98aa8e6321 to avoid
calling parseConfiguration() again, which is unfortunate but does result
in the cached information being that causes the problem being cleared
out.
This fixes "Task do_unpack does not exist for target ..." running
devtool upgrade within intel-iot-refkit.
(Bitbake rev: f120355eaec4571ba6d60fc5f7ae9e1f31d846d1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you set tracking=True when creating the tinfoil object, that ensures
history is collected for the main datastore, but at the end of parsing
the configuration, history tracking gets turned off to save time with
the result that we don't collect history for any recipes we parse.
Enable tracking when we parse a recipe (and disable it afterwards if we
enabled it) in order to fix this.
This fixes functionality in OE's devtool that relies upon variable
history (such as devtool upgrade updating PV when it's set within a
recipe).
(Bitbake rev: cc8b4c81bb589fb70774a0151f87a8d277f40f06)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a task fails during build_targets(), we need to print out the log
lines as knotty does or the user will be missing information about the
failure.
(This should get some deeper refactoring, but now isn't the time for
that.)
(Bitbake rev: 24879df071d4803db3d39ae1d5cad852daa92f28)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With config_only=False we launch the UI and it sets up a logger, whereas
when config_only=True we don't, with the result that with True we are
seeing log messages from both our logger and the one set up by the UI.
Suppress our loggers with config_only=True to avoid this.
Fixes [YOCTO #11275] (again).
(Bitbake rev: b5e3b28b7c982dd8a3991d727f25710dbf58bb80)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the server exits quickly its PID may no longer exist. Handle
this gracefully.
(Bitbake rev: c1b00a9265fa4146b8db8b7d03a51bf2bfcf9f51)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
self has a quit function and a variable. Separate this to two different
things as the current setup is prone to breakage.
(Bitbake rev: ba7e3c73d8f4d2bd1d7434b97c326e7ab935231a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Shutdown from SIGTERM currently has to wait for the handler thread to timeout.
Add a sentinel value which triggers it to loop and allows for a quick exit.
(Bitbake rev: a7591ef34ce70ff1d7aa9362d7473e6f16fbd10f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If for example you run:
bitbake -r somefile.inc
rm somefile.inc
bitbake -e
bitbake will crash with an error about not being able to find somefile.inc. This
is because it tries to reparse the base config for the early getVariable requests
before it sees the updated missing -r option.
Send the updateConfig command earlier to avoid this.
(Bitbake rev: a38164620ebdc770690c5f39ff9ed69d3f82719e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cooker.reset() can be called before we've actually setup the datastore. Gracefully
handle this case instead of the current traceback+exit.
(Bitbake rev: 8fd30ca6d271c125a8ea03ef0c5d7ab176900701)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we reload the configuration, PRSERV_HOST can change. Therefore
restart the PR Server depending on the new configuration at reparse.
Note that the server has to be started from the right process, it
can't be in the UI which shuts down as that shutdown triggers a shutdown
of its children and the PR Server shuts down too. This is why we need
pre_serve() which ensures its executed in the right context.
(Bitbake rev: 971272e84f4efe7ebd0037e164ba54f013a2a34e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows for cleaner code in cooker as any existing server is dealt
with before a new one is started.
(Bitbake rev: b8616931bc0e523a3a3bb23b4f623f8b6e71d690)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the original prefile and postfile passed when starting bitbake
server are 'sticky'. With the new memory resident model this doesn't make
sense as the server the system is started with isn't special.
This patch changes the code so the prefile/postfile are used if specified
on the commandline and not used otherwise. This makes the behaviour much
more predictable and expected and as an added bonus simplifies the code.
(Bitbake rev: 638d366234fad78f283d3a13a12b07cb0ccbe914)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
