We need to ensure the locale is UTF-8 or otherwise strange errors will
occur later on during execution - the same reason we check this in
BitBake itself. Unfortunately this check has to be before command line
parsing and therefore showing the help text in response to --help, since
that relies upon parsing bitbake's configuration (as we need to load
plugins in other layers).
Fixes [YOCTO #10908].
(From OE-Core rev: 370c6ba16c72bb52e80da098a5812ed1e09ac659)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 0a36bd96e6b29fd99a296efc358ca3e9fb5af735)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't catch this then attempting to run devtool in non-memres mode
when bitbake is already running will produce a traceback instead of just
an error message.
(From OE-Core rev: e01b75dff599ffa2b66e6608b28bbb3564365eee)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To allow devtool plugins in one layer to shadow another in a well
defined way, first search BBPATH/lib/devtool directories and then
scripts/lib/devool and load only the first found.
The previous search and load loop would load all found plugins with the
ones found later replacing any found before.
(From OE-Core rev: 1b2b8a0a80de17ea053002fdd124055d2798029a)
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When devtool creates a new workspace, it produced a README with one very
long line and no space following 'bblayers.conf'. Add a line break as was
intended.
(From OE-Core rev: 4ad1bcfc3c88ced5b7fc80c950613e31becb40f3)
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should always shut down tinfoil when we're finished with it, either
by explicitly calling the shutdown() method or by using it as a
context manager ("with ...").
(From OE-Core rev: 5ec6d9ef309b841cdcbf1d14ac678d106d5d888a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Certain recipes cannot be used with devtool extract / modify / upgrade -
usually because they don't provide any source. Return a specific exit
code (4) so that scripts such as scripts/contrib/devtool-stress.py know
the difference between this and a genuine failure.
(From OE-Core rev: ffd295fed4ab81fc0bd00bb145ef4d72c49584bf)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Python 2, argparse subparsers behaviour in Python 2 was to print
the usage information if the subparsers argument wasn't specified.
However, with Python 3.2.3 and later a subparsers argument is not
required by default, leading to errors when no arguments are specified:
AttributeError: 'Namespace' object has no attribute 'func'
Restore the previous desired behaviour of showing the help text for
devtool, recipetool and the devtool-stress script by setting
subparsers.required to True.
(From OE-Core rev: d36fdea1a7f32d97187e0e9e6d701ae8fa304e8f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Clarify slightly the intended usage of the workspace layer.
(From OE-Core rev: d9f3af6f4e6d3df30b411bbcc3c2b6f7f62c52ad)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As most of oe-test cases work for devtool and recipetool
it makes sense to switch both tools to python 3 by
explicitly referring to python3 in their shebangs.
(From OE-Core rev: dad9617809c60ec5f11d4780b0afa1cffa1efed5)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ConfigParser API was renamed to configparser in python 3.
Renamed ConfigParser -> configparser in scripts/ to make the
code working in python 3.
(From OE-Core rev: de6e98f272e623ce72e724e66920eecf10cb2d41)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If an image with the filename foo.bb could be built using the name "bar"
instead, then build-sdk would fail to create the derivative sdk.
This was because the code assumed that the file name matched the target,
which is not necessarily the case.
(From OE-Core rev: d58a326b6960be14b8a049253559aec9582b7d0d)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a recipe is added to the workspace, the signatures for the tasks
will change. This means that bitbake must be told to allow the
signatures to be different if they are in locked-sigs.inc.
This is done by creating an unlocked-sigs.inc file which contains all
the recipes in the workspace each time devtool reads the workspace.
So not only will necessary things get added, previously added items will
be removed by virtue of them no longer being in the workspace.
This also makes sure that the extensible sdk picks up unlocked-sigs.inc
as part of the configuration.
[YOCTO #9195]
(From OE-Core rev: 6b2b5ffdcb8bf885a1c756ea132e9d2c55e13dcd)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There appears to have been a lot of copy and pasting of the code
which prints tracebacks upon failure and limits the stack trace to
5 entries. This obscures the real error and is very confusing to the user
it look me an age to work out why some tracebacks weren't useful.
This patch removes the limit, making tracebacks much more useful for
debugging.
[YOCTO #9230]
(From OE-Core rev: 6069175e9bb97ace100bb5e99b6104d33163a3a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The listing of subcommands in the --help output for devtool was starting
to get difficult to follow, with commands appearing in no particular
order (due to some being in separate modules and the order of those
modules being parsed). Logically grouping the subcommands as well as
being able to exercise some control over the order of the subcommands
and groups would help, if we do so without losing the dynamic nature of
the list (i.e. that it comes from the plugins). Argparse provides no
built-in way to handle this and really, really makes it a pain to add,
but with some subclassing and hacking it's now possible, and can be
extended by any plugin as desired.
To put a subcommand into a group, all you need to do is specify a group=
parameter in the call to subparsers.add_parser(). you can also specify
an order= parameter to make the subcommand sort higher or lower in the
list (higher order numbers appear first, so use negative numbers to
force items to the end if that's what you want). To add a new group, use
subparsers.add_subparser_group(), supplying the name, description and
optionally an order number for the group itself (again, higher numbers
appear first).
(From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user specifies --basepath on the commandline, only the directory
specified should be searched for .devtoolbase. Otherwise when --basepath
is a child of the sdk directory, .devtoolbase will always be found and
devtool will only show options meant to be used within an sdk.
(From OE-Core rev: 3bb07c61220b89384a76c745e33be37aad5095c0)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're doing this in a couple of places, let's just find the recipe file
if it exists within the workspace (which it will if it's been added
through "devtool add") when we read in the workspace.
(From OE-Core rev: 81cf5580993c99050e3f4d6d891bc67534721487)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As per the changes to "devtool add", make the source tree path optional
and use the default path if none is specified.
(From OE-Core rev: 83707d1334fb094fd1877bcfd07a83866601048a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having to specify -f is a little bit ugly when a URI is distinctive
enough to recognise amongst the other positional parameters, so take it
as an optional positional parameter. -f/--fetch is still supported, but
deprecated.
(From OE-Core rev: aedfc5a5db1c4b2b80a36147c9a13b31764d91dd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For scripts that use Python's standard argparse module to parse
command-line arguments, create a subclass which will show the usage
the usage information when a command-line parsing error occurs. The most
common case would be when the script is run with no arguments; at least
then the user immediately gets to see what arguments they might need to
pass instead of just an error message.
(From OE-Core rev: d62fe7c9bc2df6a4464440a3cae0539074bf99aa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Make some minor clarifications to help text
* Drop ArgumentDefaultsHelpFormatter and just put the defaults in the
text itself where needed (because otherwise you get defaults shown for
store_true options which is somewhat confusing).
(From OE-Core rev: a90ffea30c4578fd6acda2c5945b816ad33b13f5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable access to the configuration object in register_commands() so that
we can read configuration values there; this allows us to show the
task that will be run in the command line help for the build subcommand.
(From OE-Core rev: 142d006de3235a034839ef7bbe147c56fc7af04a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For subcommands that don't actually involve the workspace, don't
auto-create the workspace.
(From OE-Core rev: 90cba7992bc1d227e242666cd486414bd4a45f7e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not change change current working directory permanently, but, only
for the duration of tinfoil initialization instead. The previous fix
caused very unintuitive behavior where using relative paths were solved
with respect to the builddir instead of the current working directory.
E.g. calling "devtool extract zlib ./zlib" would always create create
srctree in ${TOPDIR}/zlib, independent of the users cwd.
(From OE-Core rev: 4c7f159b0e17a0475a4a4e9dc4dd012e3d2e6a1f)
(From OE-Core rev: 05060699e63cd25d089e83e9aa56c11d5baa8fd8)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the following error when running devtool from a directory other
than the build directory (or the SDK base path when using within the
extensible SDK):
The BBPATH variable is not set and bitbake did not find a
conf/bblayers.conf file in the expected location.
Maybe you accidentally invoked bitbake from the wrong directory?
(From OE-Core rev: 1687ec04bfee327fe24fdfecb67db689835769f2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe is BBCLASSEXTENDed (e.g. to -native), its PN value and the
name of the bbappend will be different; we were assuming them to be the
same when reading in the workspace, leading to us seeing the base recipe
name everywhere afterwards.
Also add a test so we ensure this doesn't regress in future.
Fixes [YOCTO #8157].
(From OE-Core rev: b63fca00c2e24ad0c8b8b3c492d93ee4372fa92d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tinfoil now has its own shutdown method, use it instead of calling into
cooker - not only is it the right thing to do from an API perspective,
it also ensures proper lock handling.
(From OE-Core rev: c1f58caad4ff45efd213bf1412304a72903abe7e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it easier to extend, as a layer can add its own sub-commands.
Argument parsing is also separated into two steps, the same way it's done in
recipetool, as we need access to the global command-line arguments early,
before plugins are loaded, both for debugging arguments and for the bitbake
path (we need to load the bitbake module to get tinfoil, which is now needed
to load the plugins).
Rather than constructing tinfoil once and passing it through into sub-commands
for their use, we have to construct it for configuration metadata, use it, and
then shut it down, as some sub-commands call out to recipetool, which needs
its own tinfoil instance, and therefore needs to acquire the bitbake lock. If
we're still holding the lock at that point, that's clearly a problem.
[YOCTO #7625]
(From OE-Core rev: f9bc3b27244a141ec7273445d3ea139a047e0ddf)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use DevtoolError exception more widely for handling error cases. This
exception is now caught in the main script and raising it can be used to
exit with an error. This hopefully simplifies error handling. The
change also makes exit codes more consistent, always returning '1' when
an error occurs.
(From OE-Core rev: 2e4f1dcade7ccb581c7a390c32163ea3deeac6d5)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we run devtool, if the workspace layer already exists but isn't in
bblayers.conf (perhaps because it was previously created but
subsequently removed from bblayers.conf by the user) then we should add
it and notify the user, otherwise devtool operations won't work.
(From OE-Core rev: 313b622a6c6613092ed18a2158e090521344f6c0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Names such as glib-2.0 are valid (and used) recipe names, so we need to
support them.
Fixes [YOCTO #7643].
(From OE-Core rev: b9fd8d4d4dfae72de2e81e9b14de072e12cecdcf)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on feedback from Scott Rifenbark <scott.m.rifenbark@intel.com>
(From OE-Core rev: ec3378f3a7013e289daa0f5c52329488b861f99c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provides an easy means to work on developing applications and system
components with the build system.
For example to "modify" the source for an existing recipe:
$ devtool modify -x pango /home/projects/pango
Parsing recipes..done.
NOTE: Fetching pango...
NOTE: Unpacking...
NOTE: Patching...
NOTE: Source tree extracted to /home/projects/pango
NOTE: Recipe pango now set up to build from /home/paul/projects/pango
The pango source is now extracted to /home/paul/projects/pango, managed
in git, with each patch as a commit, and a bbappend is created in the
workspace layer to use the source in /home/paul/projects/pango when
building.
Additionally, you can add a new piece of software:
$ devtool add pv /home/projects/pv
NOTE: Recipe /path/to/workspace/recipes/pv/pv.bb has been
automatically created; further editing may be required to make it
fully functional
The latter uses recipetool to create a skeleton recipe and again sets up
a bbappend to use the source in /home/projects/pv when building.
Having done a "devtool modify", can also write any changes to the
external git repository back as patches next to the recipe:
$ devtool update-recipe mdadm
Parsing recipes..done.
NOTE: Removing patch mdadm-3.2.2_fix_for_x32.patch
NOTE: Removing patch gcc-4.9.patch
NOTE: Updating recipe mdadm_3.3.1.bb
[YOCTO #6561]
[YOCTO #6653]
[YOCTO #6656]
(From OE-Core rev: 716d9b1f304a12bab61b15e3ce526977c055f074)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton
Joshua Lock
Ola x Nilsson
Joe MacDonald
Ed Bartosh
Randy Witt
Richard Purdie
Markus Lehtonen
Christopher Larson