So far all devtool and recipetool plugins were expected
to have plugin_init function. This function is empty in
most of plugins as they don't require initialisation.
Making plugin_init optional would allow not having empty
plugin_init in every plugin.
(From OE-Core rev: b99640c89f067866b264f4ee4030fae4c2f338c0)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enables creating packages using devtool within the extensible SDK. (This
is only enabled within the extensible SDK because it provides no
advantage over just running bitbake directly there).
(From OE-Core rev: 6dc0269bca3e874582d61b40dbf0d495331fb96a)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe has been added to the workspace via "devtool add"
or "devtool upgrade" then the recipe file itself will be in the
workspace layer; if you run "devtool update-recipe" particularly in the
upgrade case you might think it would apply the upgrade to the original
recipe, but it will not - in order to remain consistent it has to update
the recipe that's in use which is the one in the workspace. Warn the
user in this situation so that they know what they need to do when they
are finished.
(From OE-Core rev: 4801b64243e57e554a593f0857dd53621d8f52e5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enhance the logic behind the 'auto' mode a bit by only updating the
SRCREV if the changes are already found upstream. The logic is simple:
update SRCREV only if the current local HEAD commit is found in the
remote branch (i.e. 'origin/<branch_name>'). Otherwise resort to
patching.
This affects a couple of the oe-selftest tests so update those as well.
[YOCTO #7907]
(From OE-Core rev: 9b9733b7d74032aef4979bec553019421e77da14)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Through -s/--disable-parallel-make, the user can turn off parallelism
on the make tool. This can be useful when debuging race condition issues.
In order to set PARALLEL_MAKE = "" a post-config file created and then
passed into the build.
[YOCTO #7589]
(From OE-Core rev: 0bf2e4b3edfc43e7a2e8d3387a9370d110533b7c)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The intention is to have a single file for each devtool feature
so devtool can grow in a modular way. In this direction, this patch creates
build.py, moving all related build features from standard.py to build.py.
(From OE-Core rev: 61bb1759f7ecb8b404f7d97573c61aef31f2f109)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrades a recipe to a particular version and downloads the source code
into a folder. User can avoid patching the source code.
These are the general steps of the upgrade function:
- Extract current recipe source code into srctree and create a branch
- Extract upgrade recipe source code into srctree and rebase with
previous branch. In case the rebase is not correctly applied, source
code will not be deleted, so user correct the patches
- Creates the new recipe under the workspace
[YOCTO #7642]
(From OE-Core rev: 4020f5d91b3e4d011150d5081d36215f8eab732e)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow the _add_md5() function to be called with a directory in order to
recursively add the files under it. Additionally, we need to skip
preserving empty directories (since directories aren't listed in the md5
file).
(From OE-Core rev: 9383af78adc854a6f6de8b1520edf3cea0c477a6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not put 'do_shared_workdir' into SRCTREECOVEREDTASKS when creating
bbappend for kernel packages. This will allow building packages that
depend on the shared build artifacts of kernel.
[YOCTO #6658]
(From OE-Core rev: 2355ccc627c0003a14693d1a023a003b7b44ea53)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable updating the installed extensible SDK from a local or remote
server, avoiding the need to install it again from scratch when
updating. (This assumes that the updated SDK has been built and then
published somewhere using the oe-publish-sdk script beforehand.)
This plugin is only enabled when devtool is used within the extensible
SDK since it doesn't make sense to use it next to a normal install of
the build system.
E.g.
devtool sdk-update /mnt/sdk-repo/
devtool sdk-update http://mysdkhost/sdk
(From OE-Core rev: 32cbd4c57fc8ca097a18929fc404c07322ef36dd)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel package needs "kern-tools-native" in order for it's
do_kernel_metadata. Thus, devtool extract for kernel in a pristine
environment fails. With the current bb.tinfoil implementation it is not
possible to run arbitrary bitbake commands - e.g. run
"bitbake kern-tools-native -c populate_sysroot" in our case. This patch
implements an ugly workaround for that problem, basically by hardcoding
this dependency and running the required bitbake task(s) before tinfoil
is initialized.
[YOCTO #6658]
(From OE-Core rev: a9eb80de164fb8a464e29bf1cc6c7cf397f36662)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change handling of kernel packages so that the "initial rev" is parsed
correctly. Also, the devtool-specific git tags (devtool-base and
devtoo-patched) are now generated for kernel packages as well.
[YOCTO #6658]
(From OE-Core rev: 65fe3e45b10c5578446c758f66840891c62cd774)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set SRCTREECOVEREDTASKS appropriately in the workspace .bbappend file
for kernel recipes. This tries to ensure that all needed tasks (esp.
configure and patch) are run when building the kernel - tasks which
would normally be disabled by externalsrc.bbclass.
[YOCTO #6658]
(From OE-Core rev: f0a3a38a653c643468452eba43a12795136720c9)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added couple of hopefully useful comments to the code.
(From OE-Core rev: 72dfe5b58c637d74971e025aef3ce0a64dc8172c)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed <image>.bbappend before generating it again as
it may cause tinfoil to fail due to its wrong content.
It's safe to do as <image>.bbappend is regenerated anyway.
(From OE-Core rev: 82c6452ca953eb32e2919d9f9e64497a15212be5)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added logger calls to show if image is modified by the
plugin or not.
(From OE-Core rev: f719e956a6263784963b6ae9514030a1a1dc2aeb)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added notification callback to <image>.bbapend to notify
user that image is modified by build-image plugin.
(From OE-Core rev: 53cb00b8af58c326e2a045cd6f8a04a24dc4c1b5)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Filtered out non-target recipes and recipes with
recipe name != package name in build-image plugin.
Isolated all logic of getting recipes in _get_recipes
function.
(From OE-Core rev: efe685711ae6f4beec06ba591c74140ce56b96af)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Made parser help message and description more clear in
build-image plugin.
(From OE-Core rev: 39714557dde70c4b1ce8d08c7e1d21fd39a1d1a6)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used logger variable name instead of LOG as it is used the rest
of the devtool code.
Pylint complains about 'logger' being invalid constant name,
but it's better to be consistent in naming.
(From OE-Core rev: a1c811df93e831a198464008564ce33ec98a3049)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 69c63728da.
Moved add_md5 back to standard.py as it's not used in
any plugin anymore.
(From OE-Core rev: 3823b7abf8c1e82e0448d7283de95422fd262135)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moved standard.py:_parse_recipe -> __init__.py:parse_recipe and
standard.py:_get_recipe_file -> __init__.py:get_recipe_file
to be able to call them from other modules.
(From OE-Core rev: f0e61a0d5597017c5f5d2dafb41118b79f505d9b)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It doesn't make sense to use it as image recipe is not
in workspace. It means that we can't do 'devtool reset'
for the recipe, which is a main point of using add_md5.
(From OE-Core rev: f69613ed9d56c6e6ba322d8c9db07b7ed802042a)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implemented new plugin to build image from workspace packages.
Plugin creates <image>.bbappend file, adds
all workspace packages to the image using IMAGE_INSTALL_append
variable in bbappend file. After that it runs 'bitbake <image>'.
(From OE-Core rev: 00bc43868da3ea2a4532215d3abef8e150c7b2e5)
(From OE-Core rev: fc35c10fed382e385f00b76abcee94a0148b4aee)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moved _add_md5 function from standard.py to __init__.py to
be able to call it from other modules.
(From OE-Core rev: ee38bb20dc7ba21dac782d8d13383f81dfedef55)
(From OE-Core rev: b07da7d38bcefe8efdd6b22bb9251bef599ef040)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Let's have the caller do this and then the function is a bit more
flexible (e.g. we can choose to parse with bbappends or not); fix up
calls to this function appropriately (of which there are only two, both
within devtool).
(From OE-Core rev: 6ba969f1ac5a1a0e277a21287fc5ae1622a6b14e)
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>
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>
Ensure that the "patches" subdirectory is removed from the right
location when S == WORKDIR (e.g. devtool extract makedevs).
(From OE-Core rev: 2062c88726400e09599aff51af95799a866b90c9)
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>
In case the user has set up externalsrc outside of devtool, force
EXTERNALSRC to blank for the recipe when extracting so that the original
source URI is still in SRC_URI and we're still able to extract it. (This
isn't a problem with devtool itself because the bbappends within the
workspace layer that apply externalsrc are explicitly filtered out when
devtool parses a recipe).
(From OE-Core rev: 5be16d639d1b78d114755bfd552ac901d0fdf4a9)
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>
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>
If patches fail to apply with git, quilt it used as a fallback. If that
happens, the code in this class is meant to handle cleanup of these patch
files. In the case where ${S} is a subdir of the git tree, the code doesn't
correctly set the patches directory.
This change correctly sets the patches directory (which is different to the
location of the git repository).
[YOCTO #7911]
(From OE-Core rev: de6e0f3af5e858960676ea291036e59105fd806f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It turns out that scp can't be used to copy symlinks because it follows
them instead of copying them, and this is by design (since it emulates
rcp which also behaved this way); the unfortunate result is that
symlinks that point to valid files on the host translate into the host
file being copied to the target (yuck). The simplest alternative that
does not have this undesirable behaviour is to use tar and pipe it over
ssh.
At the same time, it would be even better if we properly reflect file
permissions and ownership on the target that have been established
within the pseudo environment. We can do this by executing the copy
process under pseudo, which turns out to be quite easy with access to
the pseudo environment set up by the build system.
Fixes [YOCTO #7868].
(From OE-Core rev: 69adaed0e982d627ebfa57b360b0ee049ea7a276)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.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>
Continue refactoring of update_recipe() by splitting out the 'patch'
mode into a separate function.
(From OE-Core rev: cdcfedec5489a5d8d0df56bbe100e5fc2cca03af)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactor update_recipe() (i.e. the implementation of the update-recipe
command) by splitting out the 'srcrev' into a distinct function.
(From OE-Core rev: 5da26bfd8b34af9075b9b900d353df555d8f2ef0)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just refactor the code.
(From OE-Core rev: 06f6b20f040d2e4eee577bb2111351523ee97af2)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A slight simplification of the code.
(From OE-Core rev: aff88bcebe335b0277df660ac22eeed28d65da44)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Split out the logic of determining "initial rev" and "update rev" into a
separate function.
(From OE-Core rev: 17206934822aab31d93318bffea8099bf9965112)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quite often what you want to do having made customisations to a piece of
software is to apply those customisations in your own layer rather than
in the original recipe. Thus, add a -a/--append option to the
update-recipe subcommand which allows you to specify the layer to write
a bbappend into. The bbappend will be created at the appropriate path
within the specified layer directory (which may or may not be in your
bblayers.conf) or if one already exists it will be updated
appropriately.
(This re-uses code written for recipetool appendfile.)
Implements [YOCTO #7587].
(From OE-Core rev: 87d487ea4fdfb6cd30e3b3fad47732db12e86f23)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of the time when bb.note() gets called we want to see the output,
so ensure the level is set appropriately depending on the command line
options instead of being fixed at warning. (We don't want to see the
notes for fetch/unpack/patch though as they are too verbose).
(From OE-Core rev: 69f426a2d966a2228cbdc708b9ddab31005c6d96)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using tinfoil here is quicker and tidier than shelling out to
bitbake -e and interpreting its output.
(From OE-Core rev: 986ad99aee98dd5b7f30d59098dd9275097b8276)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we execute an external command, we ought to prepare for the
possibility that it can fail and handle the failure appropriately. We
can especially expect this to happen when running bitbake in this
scenario. Ensure we return the appropriate exit code to the calling
process.
Fixes [YOCTO #7757].
(From OE-Core rev: 98a716d79bfc5434a5b42d3ca683eab3eea30a41)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before this change, all files from the recipe (SRC_URI), including
patches, were added to to srctree repository when S==WORKDIR. The patch
files are useless as they are automatically applied on top of the
srctree by devtool.
This change causes devtool extract to not commit these unnecessary (and
possibly confusing) patch file(s) into srctree repository.
[YOCTO #7602]
(From OE-Core rev: 3e0ffff619e49b1f0c13e5f6a663455be3ed26af)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After OE-Core commit 67db7182faf6742b0d971d61d8c5ba34f69d2e12, PV is
appended to the end of the gcc-source PN, thus we need to handle that in
devtool and the corresponding test.
Part of the fix for [YOCTO #7729].
(From OE-Core rev: 440029dc229a566b9bead1481215d5e5760c5fe6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Recipes that fetch from git, svn or hg by OpenEmbedded convention
should normally be named with this as a suffix, since PV is meant to
be set appropriately within the recipe, so follow this. In order to
make this work we need to be able to have the version independent from
the file name, so add a -V option to recipetool create to allow this
to be specified.
* If -V is specified on the devtool add command line, ensure at PV gets
set to include this version.
(From OE-Core rev: 2b997c41c6476a13bf516586d56a9051aceb93ec)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a -f/--fetch option to fetch a remote URI (into the already
specified source tree path) and set this as SRC_URI within the recipe.
This simply wraps around the existing functionality in recipetool.
Implements [YOCTO #7644].
(From OE-Core rev: f22fd77e735fc5f4a3434e3d1f567a9d7d191cf4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If -x is specified and the specified URI was a git repository, we need
to ensure that the resulting clone is a sandalone and not one that has
pointers into the temporary fetch location or DL_DIR (since the git
fetcher does a local clone with -s). Split out the code from devtool
that already does this for "devtool modify -x" and reuse that.
(From OE-Core rev: fc47e8652ef32e7399f57c80593df90dc52d8b84)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you've done "devtool add" (or "devtool modify" without -x) then it's
possible that the external source tree is not a git repository, so we
should handle that case here instead of printing a traceback.
(From OE-Core rev: eb2147aa8facd4ef33a0749e9ae660ec686dad48)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the proper bbappend file name, don't just assume it will have a
version suffix (because it won't if the original recipe doesn't).
Fixes [YOCTO #7651].
(From OE-Core rev: 3332d68ef7b2a300ce8dcf5021497d98e5b17baa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you manually delete files in the workspace layer (which you really
shouldn't) it was possible to get yourself into the situation where you
couldn't reset because we were attempting to check if the file had been
modified and erroring out if it couldn't be opened. If the file's not
there anymore there's not much point checking if it needs to be
preserved, just skip it.
(From OE-Core rev: d2d352f7b747a97a54df9d20eb1455d166aa1ee3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We weren't adding the version into the bbappend file name when -V was
specified which meant that building or resetting failed.
Also adjust one of the tests so that we're testing devtool add both with
and without this option.
Fixes [YOCTO #7647].
(From OE-Core rev: bdbeff0cd342e31053d7203d78fc5dda611052b1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to get correct metadata, SRCREV for example.
Fixes [YOCTO #7648].
(From OE-Core rev: 8b1794559dd7fd956716179d628e61cffdce1686)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This option can be used to have a separate build directory, in order to
keep the srctree directory clean for packages that do not need to be
built in the source directory.
(From OE-Core rev: 5cc348c0a3016e4ccc1e80d099e2e197b3b38bd2)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Makes the build succeed for packages which do not support separate build
directory, e.g. zlib. The same outcome could be achieved with the
--same-dir option, but, it's generally hard to tell if a random package
would need that option. The negative side effect of this patch is that
dev srctree (of some packages that build fine without this modification)
gets dirtied by build artefacts.
(From OE-Core rev: 6ac5692426956e276ba2119f917b0f30791e6cd6)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ubuntu's default dash shell causes oe-init-build-env to behave a bit
differently - (a) it can't pick up the OE root directory and (b) it
can't see any build directory specified as a command-line argument
(since dash doesn't pass through any arguments specified to sourced
scripts). We could work around these but doing so requires some internal
knowledge of the script; a much simpler fix is just to force running the
command under bash since it's expected to be installed on every distro.
Thanks to Chen Qi <Qi.Chen@windriver.com> for this fix.
Fixes [YOCTO #7614].
(From OE-Core rev: 27942f546e6b08cdf9f2dbda2e24d237cde7f5f5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Give the correct data object ("config data" instead of "recipe data") as
an argument to oe.recipeutils.patch_recipe()
Fixes [YOCTO #7595]
(From OE-Core rev: 7d2b918019b0afe215a6489dad697afac34f73e9)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a dry-run option to the deploy-target and undeploy-target
subcommands so you can see the list of files to be deployed or
un-deployed before actually carrying out the operation.
(From OE-Core rev: b9625581f3fe72fc402632be2d87cf889301c6a2)
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>
The -q option to scp does stop the progress being shown, which is mostly
superfluous, however it also stops errors from ssh being shown - if
there's a problem, you'll just get "lost connection" which really isn't
that helpful. As a compromise, add a -s/--show-status option and
advertise this when the command fails.
(From OE-Core rev: 5cbb026212b4c8f5206a07d70b94f57edeee0839)
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>
If you haven't built the recipe yet or if the output directory (${D}) is
empty, then we should tell the user rather than have scp error out.
(From OE-Core rev: 3fd9ac277393bef5c646f16b9d8f30c277881d70)
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>
If you're testing with multiple images/devices that have the same IP
address / hostname then it can be annoying to deal with host key
mismatches all of the time. As a MITM attack is unlikely in the local
test environment, provide a command line option to pass the appropriate
options to scp/ssh to disable the host key checking.
Note: if you wish to apply this permanently, the best way is to do it
through your ssh configuration e.g. by adding the following to your
~/.ssh/config:
Host 192.168.7.2
UserKnownHostsFile=/dev/null
StrictHostKeyChecking no
(From OE-Core rev: 81dd1319112a99bc38b7a7ced0663918ac5b09a4)
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>
Consolidate code for checking compatible recipes and consider meta and
packagegroup recipes as well as package-index and gcc-source to be
incompatible.
(From OE-Core rev: 4be9bf637583b341a89af1b9924752abc7d49c94)
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>
If you point devtool modify to a source tree previously created by
devtool modify or devtool extract, then we need to try to pick up the
correct initial revision so that devtool update-recipe knows where to
start looking for commits that match up with patches in the recipe.
(From OE-Core rev: c20e10543e268ebb43074a3f8d6e7ed991e54ec8)
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>
Add a -a/--all option to allow you to quickly reset all recipes in your
workspace.
(From OE-Core rev: 0c83788b111a761f6f500b86780cc51aed255402)
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>
No functional changes, just use a unique name for each parser.
(From OE-Core rev: 5fabc59d6221c3fe7137b70e31ec2761a4276a6c)
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>
* Pass correct arguments to undeploy() function
* If an error occurs during undeploy(), exit instead of continuing
(From OE-Core rev: c938dee4b28af7e6296c86347dfa533f85605033)
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>
Because we move the workdir when extracting source, then move the source
and delete the temporary workdir, you lose the indirection symlink
pointed to by the alternates file (which is created when the fetcher
clones it from DL_DIR with -s) and the resulting repository is broken.
In any case, for a source repo that the user may put their own changes
into, we can't really rely on a clone made with -s in case the
original goes away - because of cleanall, DL_DIR disappearing, etc. So
repack the repository so that it is a complete, non-shared clone after
unpacking.
(While I'm at it, add a test for devtool modify with a git recipe which
verifies that this works.)
(From OE-Core rev: dccdde4321c48a571677995a4e1dfc583e899cbe)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable source extraction used by devtool extract / devtool modify -x for
recipes that use a shared workdir (e.g. the kernel and gcc).
(From OE-Core rev: 73a5bdc7921791b954ca717293e76c7e3091a19e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If S is outside of WORKDIR then we shouldn't try to get the relative
path in order to work out where the source subdirectory is as we do by
default.
(From OE-Core rev: 7392ecd559ef71241405c704a65da171ee216ca1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There wouldn't be any point to using these with an image recipe, so
disallow it.
(From OE-Core rev: 611c27182a6e52e159a1ce1b5bac054405c611d2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When updating git-based recipes, in a lot of cases what you want is to
push the changes to the repository and update SRCREV rather than to
apply patches within the recipe. Updating SRCREV is now the default
behaviour for recipes that fetch from git, but this can be overridden
in both directions using a new -m/--mode option.
(From OE-Core rev: 654792bb87610ee3569d02a85fa9ec071bf8ab6d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you want to be able to make use of libraries in conjunction with
devtool then we need to install them into the sysroot for other recipes
to use. Make it a configuration option in case it needs to be changed at
runtime.
(From OE-Core rev: 94f517ad8e55edfbe6f06afd963bcfeb849626ff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you've added a new recipe, you want the output cleaned when you do
devtool reset, otherwise cruft from building the recipe may remain which
could interfere with future builds.
(From OE-Core rev: 664d1a7fe8f8288fabc582d00f6e36ab29496ec5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default behaviour is to build in a separate directory to the source,
however some projects can't be built this way, so add an option to do
that (or override the automatic behaviour in the case of modify).
(From OE-Core rev: cf094ed2f616a581eb07d78db4366c83a441fde5)
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>
Deploy recipe output files to live target machine using scp
Store the files list and target machine info in localhost if deployment
is done
Undeploy recipe output files in target machine using the previous
deployment info
[YOCTO #6654]
(From OE-Core rev: cc10751aa3121218b21ec2058358f3ea02a4500a)
Signed-off-by: Junchun Guan <junchunx.guan@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.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>
