This basically calls install-buildtools from oe-core/poky, but
it ensures via command line parameters that the installation
location is stable and the downloads are preserved for reproducibility:
$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
======
Buildtools archive is downloaded into /home/alex/bitbake-builds/yocto-master-testing/buildtools-downloads/20250319141333 and its content installed into /home/alex/bitbake-builds/yocto-master-testing/buildtools
... (output from install-buildtools script)
======
It also detects when buildtools are already installed, and will direct
users what to do:
======
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
Buildtools are already installed in /home/alex/bitbake-builds/yocto-master-testing/buildtools.
If you wish to use them, you need to source the the environment setup script e.g.
$ . /home/alex/bitbake-builds/yocto-master-testing/buildtools/environment-setup-x86_64-pokysdk-linux
You can also re-run bitbake-setup install-buildtools with --force option to force a reinstallation
======
This commits includes fixes by Gyorgy Sarvari <skandigraun@gmail.com>
https://github.com/kanavin/bitbake/pull/2
(Bitbake rev: 3fe3096847046110c72b23fce37fb4a459b1d748)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run like this:
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-selftest -v bb.tests.setup
test_setup (bb.tests.setup.BitbakeSetupTest.test_setup) ... ok
----------------------------------------------------------------------
Ran 1 test in 9.223s
OK
The test does a basic run-through of init, then status/update
on an unchanged configuration, then status/update on a
configuration changed via new commits to the test layer,
then status/update on configuration changed via the top
level json config file.
Note that nothing whatsoever is fetched from the network;
the test relies entirely on synthetic data contained inside
itself, including minimal stubs for oe-setup-build and
bitbake-config-build. This data is used to create temporary
git repositories then clone them via local filesystem URIs.
Later on this can be supplemented by an oe-selftest that
tests bitbake-setup against real config files in the
official configuration repository and real layers,
templates and fragments.
(Bitbake rev: e3aa3eb46bd3196fa5415fa36e3737636fd6a1c0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Preamble
========
The latest iteration of this patchset is available at
https://github.com/kanavin/bitbake
I recommend taking the patches from there to ensure that
you are not trying out outdated code.
For the rationale and design guidelines please see this message:
https://lists.openembedded.org/g/openembedded-architecture/message/1913
Left out for now but will be done later:
- official configuration repository
- documentation
Amble *scratch* HOWTO
=====================
1. If you don't know where to start, run 'bitbake-setup init'.
Bitbake-setup will ask a few questions about available configuration choices and set up a build.
Note: 'init' sub-command can also take a path or a URL with a configuration file directly.
You can see how those files look like here:
https://github.com/kanavin/bitbake-setup-configurations
2. You can then source the bitbake environment and run bitbake to perform builds as usual:
$ . /home/alex/bitbake-builds/yocto-master-options-poky-distro_poky-machine_qemux86-64/build/init-build-env
Also, subsequent status/update commands will not require a separate --build-dir argument telling
bitbake-setup where the build is.
3. To check if the build configuration needs to be updated, run:
===
$ bin/bitbake-setup status
...
Configuration in /home/alex/bitbake-builds/poky-alex/ has not changed.
===
If the configuration has changed, you will see the difference as a diff.
...
- "rev": "akanavin/sstate-for-all"
+ "rev": "akanavin/bitbake-setup-testing"
...
If the configuration has not changed, but layer revisions referred to it have (for example
if the configuration specifies a tip of a branch), you will see that too:
===
...
Layer repository git://git.yoctoproject.org/poky-contrib checked out into /home/alex/builds/poky-alex/layers/poky updated revision akanavin/sstate-for-all from 6b842ba55f996b27c900e3de78ceac8cb3b1c492 to aeb73e29379fe6007a8adc8d94c1ac18a93e68de
===
4. If the configuration has changed, you can bring it in sync with:
$ bin/bitbake-setup update
Note that it will also rename/preserve the existing build/conf directory, and print changes
in bitbake configuration (diff of content of build/conf/) if that has changed. I can't
at the moment think of anything more clever that is also not much more brittle or complex
to implement, but open to suggestions.
Terminology
===========
- 'top directory' means the place under which bitbake-setup reads and
writes everything. bitbake-setup makes a promise to not touch anything outside of
that, unless otherwise directed to by entries in settings (currently
there is one such setting for fetcher downloads for layers and config
registries). Top directory can be selected by an environment variable, a command line option,
or otherwise assumed to be ~/bitbake-builds/. If BBPATH is in environment
(e.g. we are in a bitbake environment), then the top directory is
deduced from that and doesn't need to be specified by hand.
- 'settings' means bitbake-setup operational parameters that are
global to all builds under a top directory. E.g. the location of
configuration registry, or where the bitbake fetcher should place the
downloads (DL_DIR setting). Settings are stored in a .conf file in ini
format just under the top directory.
- 'build' means a tree structure set up by 'bitbake-setup init',
consisting of, at least, a layers checkout, and a bitbake
build. It maps 1:1 to the json data it was constructed from, which is
called 'build configuration'. Build configurations are constructed from
generic configurations that may involve making one or more choices
about available options in them. Generic configurations are files, URLs
or are obtained from git repositories called 'config
registries', in which case they can be listed with 'bitbake-setup
list'. There can be multiple 'builds' under a top directory. Here are
two example generic configurations that showcase this:
https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-options.conf.jsonhttps://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-nested-configs.conf.json
- 'bitbake-setup status' will tell if a build is in sync with
the generic configuration it was made from. 'bitbake-setup update' will bring a build
in sync with a configuration if needed.
- 'bitbake build' means a particular sub-tree inside a build that
bitbake itself operates on, e.g. what is set in BBPATH/BUILDDIR
by oe-init-build-env. conf/* in that tree is 'bitbake configuration'.
Bitbake configurations are constructed from templates and fragments,
with existing mechanisms provided by oe-core. The configuration file
format is specified such that other mechanisms to set up a
bitbake build can be added; there was a mention of ability to specify
local.conf content and a set of layers directly in a configuration. I
think that scales poorly compared to templates and fragments, but I
made sure alternative ways to configure a bitbake build are possible
to add in the future :)
- 'source override' is a json file that can be used to modify revisions
and origins of layers that need to be checkout into a build (e.g.
when master branches need to be changed to master-next for purposes
of testing). Such a file is specified with a command-line option to 'init'
and an example can be seen here:
https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-next.override.json
This commit includes fixes by
Ryan Eatmon <reatmon@ti.com> https://github.com/kanavin/bitbake/pull/1
Gyorgy Sarvari <skandigraun@gmail.com> https://github.com/kanavin/bitbake/pull/2
Johannes Schneider <johannes.schneider@leica-geosystems.com> https://github.com/kanavin/bitbake/pull/3https://github.com/kanavin/bitbake/pull/5
(Bitbake rev: b96154aeb1fc89184ac245e0d68e6e726fe80c04)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lastpids has not been used for almost 10 years.
* There is no longer any need to use running_pids to keep track of the
order the pids in running_tasks were added as dicts are guaranteed to
remember the insertion order since Python 3.7.
(Bitbake rev: 562b5bf0be2883144391e7030a9dce6a233802ac)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having multiple builtin config fragments for the same variable
(eg OE_FRAGMENTS = "... machine/A ... machine/B") is not supported.
Warn the user to make them fix this but continue with the normal
variable evaluation : the last affectation "wins".
Added warning looks like:
WARNING: Multiple builtin fragments are enabled for machine via variable OE_FRAGMENTS: machine/qemux86-64 machine/test machine/qemux86-64. This likely points to a mis-configuration in the metadata, as only one of them should be set. The build will use the last value.
(Bitbake rev: 1c12aa23f6678dc289fc0e0d8b4dad311bd39c35)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Imagine a machine fragment machine/A and a configuration which sets:
MACHINE = "B"
MACHINE:forcevariable = "C"
As I understand it, the fragment behaviour was intended to replace the
MACHINE = "B", so the override would still be active. The current code
replaces all variable overrides.
parsing=True, switches to the other behaviour, which I believe was the
design intent and the behaviour users would expect.
This is useful to allow test configurations to override a MACHINE setting
without change the fragments which would complicate the test code.
(Bitbake rev: f65bc6aaf4c11bc7e566c895209c093627a3015b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current documentation is lacking details on the different kinds of
directories for putting classes as well as the order in which BitBake
includes files (classes or include files).
This patch does the following changes:
- Mention the missing classes-recipe and classes-global when applicable.
- Add a Class Types section detailed the three different directories for
putting classes.
- Move the existing section on locating classes/include files below the
documentation on the different directives (include/require/inherit).
- Extend the documentation on locating files with include/require and
inherit to give proper examples, hopefully demystifying this
mechanism a bit.
[YOCTO #15724]
(Bitbake rev: 7bd36f6c6d33211bb2a6b6fc6d40bdbd83b8b7c3)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simple tests for various ways to include and require configuration
files.
(Bitbake rev: bdcb67824172ed5cd76fa0274dc3d27aeb52e77c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to call file.flush() as the last call within a file
context manager since ending the context will close the file and thus
flush it.
(Bitbake rev: 90d5ce926d434d60d6df28b7d77b3cbc9b62ce14)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tags for bitbake 2.8.6 and 2.8.7 have been removed from the git: use
some other ones.
(Bitbake rev: dcf12947954f3184d99fbf9813b3f3f667dacc5f)
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a recipe specifies a git SRC_URI along with revision and tag, but only the
revision is present in the local clone without the tag (because it was tagged after
it was cloned), then unpacking fails with the following error:
... rev-list -n 1 1.0 failed with exit code 128, output:\nfatal: ambiguous argument \'1.0\': unknown revision or path not in the working tree
This happens because the during the download step only the revision's presence is
verified to decide if the repository needs to be updated.
To avoid this, check also if the tag is present in the local repository, when the "tag"
tag is specified.
(Bitbake rev: 546b347b4d3d82c01ecc99f45296f66e44638adc)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactoring prints, print() functions were eliminated from all loops and it uses
"\n".join(...) in a single print() call for better performance.
(Bitbake rev: c32c3d9b83818661e12f3e437563ab4e1fa05e15)
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Optimize printing in footer update with use a StringIO buffer and it
prints content to terminal in a single call in every cycle.
(Bitbake rev: 32ba622d78f20b231f30f848379b4bbc3d7414da)
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prior to commit aa84a900e ("cooker: Ensure delays are accurately transfered to
the idle loops from runqueue"), this was necessary. But now retval is returned
directly.
(Bitbake rev: c2eb4336fe10b1bf8bbc6291c32ca362840f39e1)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Marks bb.utils.explode_deps as callable from filter functions
(Bitbake rev: bb07003641e76de994482f7835a432f20297af96)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a new setVarFilter() API to the data store allowing filters to be
applied to variables.
Note that filters are applied to the non-override part of the variable name
so a filter set against RDEPENDS would apply against RDEPENDS:${PN} and
friends.
The filter function is applied before returning the final variable value.
(Bitbake rev: a9471c10d1de039474ddb4738abd286b928d82f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the python API for applying filters to a string and being able to
register functions as filters.
Filter functions are pure functions where an input is translated into
an output and there are no external data accesses. This means translations
can be cached as they won't change.
(Bitbake rev: 7d25d7511ca14213eea78ee739d260295cfa4045)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When parsing failures occur, trap KeyError to avoid these kinds
of tracebacks (from a parsing error in meta-ti).
bb.parse.ParseError: ParseError at /srv/pokybuild/yocto-worker/check-layer-nightly/build/meta-ti/meta-ti-bsp/recipes-kernel/linux/linux-ti-mainline_git.bb:6: Could not inherit file classes/${KERNEL_BASE_CLASS}.bbclass
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/command.py", line 123, in runAsyncCommand
self.cooker.updateCache()
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 1639, in updateCache
if not self.parser.parse_next():
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2314, in parse_next
self.shutdown(clean=False, eventmsg=str(exc))
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2209, in shutdown
read_results()
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2195, in read_results
self.result_queue.get(timeout=0.25)
File "/usr/lib/python3.10/multiprocessing/queues.py", line 122, in get
return _ForkingPickler.loads(res)
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cache.py", line 338, in __setstate__
setattr(self, key, self._restore(state[key], pid))
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cache.py", line 318, in _restore
ret[dep] = map[mapnum]
KeyError: 156
(Bitbake rev: 750c68ee7ee3f3d4518348e4c948243504880770)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO 15917]
When fetching a git repository the .gitattributes file is scanned, checking if LFS
support is required for the repository. This scan checks if the word "lfs" is present
in the file, however the used regex doesn't account for comments, which makes some
repositories[1] be to misidentified as requiring LFS support (which fails fetching, in case
lfs support isn't installed on the build host).
To avoid it, change the used regex to ignore lines starting with "#".
[1]: e.g. https://github.com/MicrochipTech/cryptoauthlib
(Bitbake rev: 7917a758fc328747116c7899e689171bd0efc883)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a couple more examples to the wildcarding section to make sure
readers understand it's not just a single character wildcard.
(Bitbake rev: 572062ba1f0a2953a62ef1974e35134fcb462f5e)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rewrite the include and include_all sections to drive home the fact
that the include_all directive is relevant in only very specific
cases, and not something developers should expect to use in normal
operation.
(Bitbake rev: 4b3bfe70d02cc1c11972357e2dc595acc75056e5)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When recreating the uri in wget's checkstatus method, we only use the
scheme, netloc and path. This completely strips the query parameters
from the final URI and potentially breaks the checking functionality
from certain fetchers.
This is the case for the Azure storage fetcher, as it requires a SAS
token that is formatted as a series of query parameters. The error
manifests itself when using a private storage account as a PREMIRROR or
SSTATE_MIRROR (since regular SRC_URI won't run the checkstatus).
This problem is present in scarthgap, but wasn't in kirkstone.
CC: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(Bitbake rev: 096301250455e2a83bdd818a56317c62436c9981)
Signed-off-by: Philippe-Alexandre Mathieu <pamathieu@poum.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This API is no longer used and bitbake has moved beyond Python 2.7.3 as
the minimum version, so remove it.
(Bitbake rev: 0eb7b5dd512ed8d8b77b5779858b9fbd99edb4a4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3.14 changes the default multiprocessing context from "fork" to
"forkserver"; however bitbake heavily relies on "fork" to efficiently
pass data to the child processes. As such, make "fork" context in the bb
namespace and use it in place of the normal multiprocessing module.
Note that multiprocessing contexts were added in Python 3.4, so this
should be safe to use even before Python 3.14
[YOCTO #15858]
(Bitbake rev: 62be9113d98fccb347c6aa0a10d5c4ee2857f8b6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit d591d7633fe8 ("fetch/git: Rework tag parameter handling"),
update the description of the tag= parameter for the Git fetcher.
(Bitbake rev: 85b31a55d114a1430868233d56573b470fef8908)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream servers are having issues so switch to our own shadow copy
of the repo.
(Bitbake rev: e910c7cd24fd366d6756641cd599c4efeb492e2a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use a more logical name for the profile reports and put each report
into a separate file since people struggle to discover them currently.
(Bitbake rev: a8145c84e0899285a5e6a809f1515118b002b106)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running "time bitbake -pP idle" with a valid cache shows around 800,000
calls to enum creation from python's signal.py. We don't care about this
overhead and it adversely affects cache load time quite badly.
Try and use _signal directly, falling back to signal, which avoids
this overhead we don't need and makes cache loading much faster.
(Bitbake rev: ee5fce67ce35b025c68aa61e2e758903269ee346)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Starting with python 3.12, profiling now stays enabled over threads yet
you can't extract the profile data in the threads themselves, which makes it
difficult to use for our use case.
Our main loop starts the idle loop which starts the parsing threads and this
means we can't profile in the main loop and the parsing threads or the idle
loop at the same time due to this.
Add options to the commandline so you can specify which piece of bitbake
you want to enable profiling for. This allows some profiling with python 3.12
onwards rather than crashing.
(Bitbake rev: 09f29a4968841ee5070f70277ba8c253bb14f017)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible for multple bitbake threads to empty ui_queue in parallel
leading to duplicate console messages and much confusion when debuging.
Use the lock to extract the queue data which means only one thread will
processing, removing the duplicate out of order messages.
(Bitbake rev: 945095602e40d54efb8de494218f4a2b25c9969f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have code duplication in the way we handle profiling of code sections.
Create a common function in utils which covers this.
The main loop and idle loop profile files were also reversed. Fix this and the naming,
removing a couple of unused variables containing the profile log names in the process too.
(Bitbake rev: b4f6bae97ac9607420fc49fd4c9e957d89c9a5f3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the server is quickly stopped, we see tracebacks in the locks
due to the file not existing. Hide these as they're not errors.
(Bitbake rev: a7e1a07e9ef7e6f6a1bcaf567d7916a8ee1ef087)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test behavior did not change visibly though.
"bitbake-selftest bb.tests.runqueue" passes completely, just like before.
(Bitbake rev: 1751aed08f8472f20fcfbadbb09d35f951904952)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of pre-partitioning which jobs will go to which parser
processes, pass the list of all jobs to all the parser processes
(efficiently via fork()), then used a shared counter of the next index
in the list that needs to be processed. This allows the parser processes
to run independently of needing to be feed by the parent process, and
load balances them much better.
(Bitbake rev: 373c4ddaf0e8128cc4f7d47aefa9860bd477a00f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If parsing ends early and unexpectedly, add some internal values
to better understand why/how it failed.
(Bitbake rev: 775f9720a17c9f3d6815d42c733ab5aaaa53749c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We sometimes see hangs in parsing during automated testing. It appears that
SIGINT was sent to the underlying processes which see KeyboardInterrupt but
they're stuck trying to write into the results pipe. The SIGINT was probably
from some kind of parsing failure which doens't happen often, hence the hang
being rare (in the incompatible license selftests from OE).
This patch:
* sets a flag to indicate exit upon SIGINT so the exit is more graceful
and a defined exit path
* empties the results queue after we send the quit event
* empties the results queue after the SIGINT for good measure
* increases the 0.5s timeout to 2s since we now have some very slow to
parse recipes due to class extensions (ptests)
This should hopefully make the parsing failure codepaths more robust.
(Bitbake rev: 5b533370595f83b87e480bace3e0b42c9ba61e22)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
