All packages that support the menuconfig task will be able to run
devtool menuconfig command. This would allow the user to modify the
current configure options and create a config fragment which can be
added to a recipe using devtool finish.
1. The patch checks if devtool menuconfig command is called for a valid
package.
2. It checks for oe-local-files dir within source and creates one if
needed, this directory is needed to store the final generated config
fragment so that devtool finish can update the recipe.
3. Menuconfig command is called for users to make necessary changes.
After saving the changes, diffconfig command is run to generate the
fragment.
Syntax:
devtool menuconfig <package name>
Ex: devtool menuconfig linux-yocto
The config fragment is saved as devtool-fragment.cfg within
oe-local-files dir.
Ex:
<workspace_path>/sources/linux-yocto/oe-local-files/devtool-fragment.cfg
Run devtool finish to update the recipe by appending the config fragment
to SRC_URI and place a copy of the fragment within the layer where the
recipe resides.
Ex: devtool finish linux-yocto meta
[YOCTO #10416]
(From OE-Core rev: 417feb559a74b367315e8658d6ba868a4f8d1340)
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If kernel source is not already downloaded i.e staging kernel dir is
empty, place a copy of the source when the user runs devtool modify
linux-yocto. This way the kernel source is available for other packages
that use it.
[YOCTO #10416]
(From OE-Core rev: bb42ab90835e8ec2f1dfbb35056c353784693266)
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the regular devtool modify flow, the kernel source is fetched by
running do_fetch task. This is an overhead in time and space.
This patch updates modify command to check if the kernel source is
already downloaded. If so, then instead of calling do_fetch, copy the
source from work-shared to devtool workspace by creating hard links
else run the usual devtool modify flow and call do_fetch task.
[YOCTO #10416]
(From OE-Core rev: 3c3a9bae296f849dbfe03942282f44036e6fa1fb)
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As part of upgrading a recipe we create the upgraded recipe file in the
workspace and then try to parse it so we can then make further
modifications. If for some reason that parsing fails then the failure
was not being handled very well - the broken recipe was being left in
place, breaking parsing until it was removed by hand. Fix that by adding
a call to the cleanup function, and fix the following issues:
* Fix the cleanup function which doesn't look like it has ever worked
due to a typo in the function call
* Fix double-printing the error message
* Remove usage of DevtoolError in this case (DevtoolError is for simple
usage errors, not this kind of issue which may be the result of a
bug).
We're still printing a traceback in this scenario but at least it
doesn't break the build system requiring manual cleanup. I also
introduced a command-line option to preserve the broken upgraded recipe
file(s) for debugging purposes.
(The reproducer for this is "devtool upgrade libnewt-python", however
you need to check out revision b82ea144e1
or earlier since that recipe has now been absorbed into the libnewt
recipe. The libnewt-python recipe was causing an issue with the upgrade
because it actually included the libnewt recipe using ${PV} in the
include statement, and of course PV was changing in the upgrade.)
Fixes [YOCTO #13404].
(From OE-Core rev: c519ac360796675d7fc09a5250d21f0f5b6236fc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently `devtool finish RECIPE meta' will silently succeed even
if there are multiple layers having the same base name of 'meta'.
e.g. meta layer from oe-core and meta layer from meta-secure-core.
We should at least give user a warning in such case. With the patch,
we will get warning like below.
WARNING: Multiple layers have the same base name 'meta', use the first one '<PROJ_DIR>/oe-core/meta'.
WARNING: Consider using path instead of base name to specify layer:
<PROJ_DIR>/oe-core/meta
<PROJ_DIR>/meta-secure-core/meta
(From OE-Core rev: 2c8740f543c38dbaef3345e40827ef48b3f75405)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds SPDX license headers in place of the wide assortment of things
currently in our script headers. We default to GPL-2.0-only except for the
oeqa code where it was clearly submitted and marked as MIT on the most part
or some scripts which had the "or later" GPL versioning.
The patch also drops other obsolete bits of file headers where they were
encoountered such as editor modelines, obsolete maintainer information or
the phrase "All rights reserved" which is now obsolete and not required in
copyright headers (in this case its actually confusing for licensing as all
rights were not reserved).
More work is needed for OE-Core but this takes care of the bulk of the scripts
and meta/lib directories.
The top level LICENSE files are tweaked to match the new structure and the
SPDX naming.
(From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cml1 and ccmake bbclasses generate configuration fragment source
files that must be exported from the WORKDIR as a source file to be
preserved across builds. This change adds detection of the current
recipes inherited classes and for cml1 and ccmake classes checks for the
specific generated configuration fragment files. These files are then
exported by devtool and included as SRC_URI files from within the target
layer.
(From OE-Core rev: 7a1fabe4a24552ce8a50c8d6009969ca52a5fd27)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Devtool creates a git repository for extracted sources in a temporary
directory and then moves it to a final destination after patching is
done. Unfortunately devtool is not aware that some of its git operations
may have caused git garbage collector to start in background. If timing
is just right a repository move fails because GC is removing git objects
while they are being moved.
The issue was hit on Krogoth release, but the code that moves created
git repository is still the same.
Disable gc.autodetach to make GC run synchronously and block git until
it is done.
Traceback (most recent call last):
File "<snip>/openembedded-core/scripts/devtool", line 342, in <module>
ret = main()
File "<snip>/openembedded-core/scripts/devtool", line 329, in main
ret = args.func(args, config, basepath, workspace)
File "<snip>/openembedded-core/scripts/lib/devtool/standard.py", line 352, in extract
initial_rev = _extract_source(srctree, args.keep_temp, args.branch, False, rd)
File "<snip>/openembedded-core/scripts/lib/devtool/standard.py", line 644, in _extract_source
shutil.move(srcsubdir, srctree)
File "/usr/lib/python2.7/shutil.py", line 299, in move
copytree(src, real_dst, symlinks=True)
File "/usr/lib/python2.7/shutil.py", line 208, in copytree
raise Error, errors
Error: [('/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/5e', '<snip>/build/grpc/grpc_src/.git/objects/5e', "[Errno 2] No such file or directory: '/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/5e'"), ('/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/57', '<snip>/build/grpc/grpc_src/.git/objects/57', "[Errno 2] No such file or directory: '/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/57'"), many git objects ... ]
(From OE-Core rev: 3da578a79195a63fb6d4bbd68d8f1548defd205f)
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_patch rule of SDK's workspace/appends/linux-*.bbhappend may fail if script are not written in Python
that was the case with Phytec's BSP, the fix was to replace the do_patch rule with :
do_patch[noexec]="1" when the file was generated in scripts/lib/devtool/standard.py
(From OE-Core rev: e51cb385e5573c7069de6e8308b9b68eb4a3a162)
Signed-off-by: Yann CARDAILLAC <yann.cardaillac@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow the use of an alternate SSH executable for deploy-target and
undeploy-target. The command can be specified with -e / --ssh-exec.
(From OE-Core rev: c2684740d7fd3aeb60b3ec7888000097effe82f4)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default behaviour is to show just recipes needing upgrades, but for
automated reports showing all recipes can be useful.
(From OE-Core rev: 29e064ac6bd8d1ef74c280bf85bf8428c37ba014)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The check_commits logic assumes that both devtool-base and args.branch
exist in the git repo that it is operating on. In order to prevent
errors at that point it's best to first ensure that both of these refs
actually exist. If they don't both exist then the check_commits logic
should just be skipped, as it would be if the repo wasn't originally
checked out by devtool.
Previously if a user removed the args.branch branch from their devtool
cloned repo this code would crash on adding the repo with -n. The crash
would look like this:
Traceback (most recent call last):
File "/home/ddedrick/src/poky/scripts/devtool", line 344, in <module>
ret = main()
File "/home/ddedrick/src/poky/scripts/devtool", line 331, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ddedrick/src/poky/scripts/lib/devtool/standard.py", line 812, in modify
(stdout, _) = bb.process.run('git log devtool-base..%s' % branch, cwd=srctree)
File "/home/ddedrick/src/poky/bitbake/lib/bb/process.py", line 178, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git log devtool-base..devtool' failed with exit code 128:
fatal: ambiguous argument 'devtool-base..devtool': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
(From OE-Core rev: f13a3490fdb404bbd4c77e45b83540d6deec1358)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of
overrides. Previous to these changes it would find every override to
SRC_URI and add it to the list. This would duplicate instances where
SRC_URI is modified multiple times with the same override like:
SRC_URI_append_foo += "file://0001-foo.patch"
SRC_URI_append_foo += "file://0002-bar.patch"
A bbappend might also overwrite a SRC_URI override, which would also
cause multiple instances to occur.
When there are multiple instances of the same override in
DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating
override branches. The failure occurs when attempting to create the same
override branch a second time and looks like this:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:devtool_post_patch(d)
0003:
File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202, function: devtool_post_patch
0198:
0199: for override in extra_override_list:
0200: localdata = bb.data.createCopy(d)
0201: if override in default_overrides:
*** 0202: bb.process.run('git branch devtool-override-%s %s' % (override, devbranch), cwd=srcsubdir)
0203: else:
0204: # Reset back to the initial commit on a new branch
0205: bb.process.run('git checkout %s -b devtool-override-%s' % (initial_rev, override), cwd=srcsubdir)
0206: # Run do_patch function with the override applied
File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run
0174: if not stderr is None:
0175: stderr = stderr.decode("utf-8")
0176:
0177: if pipe.returncode != 0:
*** 0178: raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
0179: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of 'git branch devtool-override-foo devtool' failed with exit code 128:
fatal: A branch named 'devtool-override-foo' already exists.
(From OE-Core rev: 90f667db2219f04e6d61588cd61056d3d8da6d7d)
Signed-off-by: Dan Dedrick <ddedrick@lexmark.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a fixup for: e1ba46109e
devtool deploy-target --strip foo root@192.168.7.2
ended up with:
Traceback (most recent call last):
File "/home/user/bar_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/
devtool", line 344, in <module>
ret = main()
File "/home/user/bar_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/
devtool", line 331, in main
ret = args.func(args, config, basepath, workspace)
File "/home/user/bar_sdk/layers/poky/scripts/lib/devtool/
deploy.py", line 187, in deploy
rd.getVar('base_libdir'))
TypeError: strip_exbar() missing 1 required positional argument: 'd'
(From OE-Core rev: bc349b2d99d74f6d7fb590fd97750e5ff8d6e6c4)
Signed-off-by: Adrian Freihofer <adrian.freihofer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add -c (--clean) optiont to 'devtool build' command so that users
could easily clean things up when using devtool.
I encountered a problem about do_prepare_recipe_sysroot failure
when using `devtool build' command and I found myself in a situation
where I either have to use `bitbake' command to clean things up or
use `rm' to remove the directories under ${WORKDIR}.
So add a clean option as it would be helpful when users want to clean
things up to prepare an environment for a clean build.
(From OE-Core rev: 29d790cdeff19e520a35ec5902d6deaae8665492)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The warn method is deprecated. We should use the documented warning instead.
Quoting from the python's official doc:
"""
Note: There is an obsolete method warn which is functionally identical to warning.
As warn is deprecated, please do not use it - use warning instead.
"""
(From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that downloading file from updateserver fails. In
this case, we should error out instead of continue.
We have users reporting unexpected behavior of 'devtool sdk-update'.
When an invalid url is supplied, e.g., `devtool sdk-update http://invalid',
the program reports 'Note: Already up-to-date'.
This is obviously not expected. We should error out in such case.
(From OE-Core rev: 449564783dfb162536a2f772b3a8704973221e0f)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is very useful for updating patch context so that any fuzz is eliminated.
Simply issue:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Without this flag, devtool will not deem the commits in the workspace
different to patches in the layer, even if the commits have different,
up-to-date context line in them.
(From OE-Core rev: 7e1d1887be8faaaab9996fca9a3fd750aeb7b62f)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* We now match on more than just target recipes, so don't specify that
only target recipes are searched.
* We're printing the SUMMARY value in addition to the name, so mention
that so it's clear where that text is coming from.
* Remind users that they should use quotes around the keyword to avoid
shell expansion when using regular expressions.
(From OE-Core rev: cc68971557fe065e59ff47657f650051eb85db3c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If pkgdata isn't present or is incomplete, then you get either a
traceback or you don't see the results you were hoping for. The recipe
cache that bitbake collects during startup contains some useful
information for each recipe that we could search through as well, and
we can access it easily using tinfoil's all_recipes() API function,
so add some code that does that. (We still show a warning if pkgdata
isn't present, as there are certain dynamic packages that are generated
at packaging time that won't show up in the cache).
One side-effect of this is that we will start showing non-target
recipes - that's actually a good thing, since seeing those is useful,
however we exclude nativesdk recipes when in the eSDK to avoid confusion
since nativesdk isn't directly applicable there.
Fixes [YOCTO #12356].
(From OE-Core rev: b8406383886d09a80a9a002150dcf364fa9902d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user doesn't specify a port then we should avoid specifying one
on the ssh/scp command line in case the user has configured one for the
host they are connecting to, which was being overridden unnecessarily.
Fixes [YOCTO #12381].
(From OE-Core rev: f1020eef09fada7ef2231d5528576553f3f6bfe1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After OE-Core rev 5e3fe00a0233d563781849a44f53885b4e924a9c we call
os.path.abspath() on the original layer path, but we later compare that
to the destination layer path. If that layer path isn't absolute but is
effectively the same path, it should be writing to the original recipe
but because we weren't making it absolute we were writing a bbappend
instead. Call os.path.abspath() on the destination path as well to avoid
that.
(From OE-Core rev: a85a78dcf226d160e9b504bfa67b306a9175ac29)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the .devtool_md5 file doesn't contain a reference to the bbappend
file (e.g. because devtool was interrupted before it could write that
out) then _check_preserve() won't delete it, so we need to delete it
separately because otherwise the recipe won't actually be reset.
(From OE-Core rev: 751d27600a3df18d96baaa48696acf33ee964bec)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix two aspects of handling BBCLASSEXTENDed targets (e.g.
openssl-native) that have been run through "devtool upgrade":
* Fix recipe name not showing up in "devtool status"
* Fix "devtool reset" not deleting empty directories under the recipe
directory within the workspace, which may lead to problems if you
subsequently run "devtool upgrade" on the same target again
(From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
singletask.lock is written out while certain tasks execute for recipes
that have externalsrc.bbclass enabled - this includes recipes in
devtool's workspace. It appears that there's a race where
singletask.lock will be there one minute and then when we try to get the
file checksum of it (since we want to know if anything in the source
tree has changed) it will be gone, and git chokes. To fix that, add
singletask.lock to .git/info/exclude in the repository, regardless of
whether we created the repository or not. In any case singletask.lock
should never be tracked by git, so this is a good thing to be doing for
that reason as well.
This fixes oe-selftest failures in test_devtool_modify that we've seen
on the Yocto Project autobuilder:
bb.data_smart.ExpansionError: Failure expanding variable
do_compile[file-checksums], expression was ${@srctree_hash_files(d)}
which triggered exception CalledProcessError: Command
'['git', 'add', '-A', '.']' returned non-zero exit status 128.
Note that this only fixes this issue for devtool; if you are using
externalsrc independently of devtool there's a chance this will still
be an issue unless you add singletask.lock to your .gitignore.
(From OE-Core rev: 334ba846c795fc0d8c73ce05a1b0882739c86650)
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>
Specifically, 'devtool upgrade' will now do these things:
1) determine if any of the license checksums need updating; if so,
write the new checksums into the LIC_FILES_CHKSUM value in the recipe
that is written to the workspace;
2) print a notice to the standard output:
NOTE: New recipe is /home/ak/development/poky/build/workspace/recipes/puzzles/puzzles_git.bb
NOTE: License checksums have been updated in the new recipe; please refer to it for the difference between the old and the new license texts.
3) and the cool part: devtool will create a diff of the old and new licenses,
and write the diff into the workspace recipe as a comment, like this:
======
FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'.
The following is the difference between the old and the new license text.
Please update the LICENSE value if needed, and summarize the changes in
the commit message via 'License-checksum-change:' tag.
(example: 'License-checksum-change: copyright years updated.')
The changes:
--- LICENCE
+++ LICENCE
@@ -1,8 +1,9 @@
This software is copyright (c) 2004-2014 Simon Tatham.
Portions copyright Richard Boulton, James Harvey, Mike Pinna, Jonas
-Klker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
-Schmidt, Steffen Bauer, Lennard Sprong and Rogier Goossens.
+Kölker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
+Schmidt, Steffen Bauer, Lennard Sprong, Rogier Goossens and Michael
+Quevillon.
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
======
(From OE-Core rev: ccb37f9e81eb78ed0eb2a238d7c3e196db9b2f72)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Specifically, 'devtool upgrade' will use the latest upstream release if available
or latest commit if upstream never makes releases.
(From OE-Core rev: 45b4242b105ad36e94ae15a96d588a58b917b8e8)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command queries the upstream server for what the latest release is and prints
the output; it is a much neater way to find out these things than fumbling with distrodata,
'bitbake -c checkpkg' and awkward to read csv output in a file.
Examples:
python3 (tarballs):
NOTE: Current version: 3.5.3
NOTE: Latest version: 3.6.3
rpm (git):
NOTE: Current version: 4.13.90
NOTE: Latest version: 4.14.0
NOTE: Latest version's commit: da3720f62e57648fb1dc2a632744d38866139971
puzzles (git without version tags):
NOTE: Latest commit: ee8ea9b9785964694cb2b3ad77c3fb2460f49510
(From OE-Core rev: e8f5b5cc25ce7a9882f21473cefc47edcebf77d4)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have a recipe that uses overrides to conditionally extend
SRC_URI to add additional patches, then you will often need to update
those patches if you're making other changes to the source tree (for
example if you're upgrading the underlying source). Make this possible
with devtool by creating devtool-override-* branches for each override
that conditionally appends/prepends SRC_URI, and have devtool
update-recipe / finish check each branch out in turn and update the
corresponding patches.
A current example of a recipe that does this is the quota recipe - it
applies an additional patch if musl is the selected C library (i.e.
libc-musl is in OVERRIDES).
Note that use of this functionality does require some care - in
particular, updates to patches that appear on the main branch (named
"devtool" by default) should be made there and not only on one of the
specific devtool-override-* branches that are created for each override.
The recommended procedure is to make the changes you want to make to the
main branch first, then check out and rebase each devtool-override-*
branch, testing each one by activating the corresponding configuration,
and then finally run devtool finish.
Fixes [YOCTO #11516].
(From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8)
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 not sure what changes devtool finish is going to make, or
you're not sure you're finished with your modifications, it is useful to
be able to see what devtool finish is going to do beforehand, so add
a -N/--dry-run option to make that possible.
(It's also very useful for debugging devtool finish itself.)
(From OE-Core rev: 05f2d5d2ce00c53825ccea5cd9c2262f9d27a638)
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 file is going to be effectively removed from the destination by
devtool finish, we should report that rather than just reporting that
we're removing files from the workspace. This is a little tricky because
the way we actually operate when finishing is to:
(1) remove all original files (as recorded by devtool upgrade, if that
was used)
(2) as part of updating the recipe file, remove the files from next to
the new recipe (i.e. in the workspace for an upgrade, real recipe
otherwise) corresponding to commits not in the git tree
(3) copy over remaining files from the workspace to the destination
To report the files removed with respect to what was originally there,
we need to swap steps 1 and 2 so we can see what no longer exists after
the deletion, and suppress the reporting currently done in step 2 -
however, we still want to report removal in step 2 for the non-upgrade
case, so the latter is conditional.
(From OE-Core rev: db1d663507509cac9d97d7c96ac8590478767ba2)
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 the files that the devtool-source class is supposed to create in the
source tree aren't found in the temporary directory then we know that
the class hasn't worked properly - say that explicitly.
(From OE-Core rev: 4621152509c037532b133e5e6d5b73bda7ddb602)
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>
* Only log one warning message instead of one per line
* Be a bit more verbose
* "if list" is more pythonic than "if len(list)"
(From OE-Core rev: 2d11e9e6e73648c1cb514c0c10111c7886acae78)
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 the directory where the source code extracts to changes (for
example, when upgrading iucode-tool from 1.5 to 2.1.1, the subdirectory
in the tarball changed from "iucode_tool-${PV}" to "iucode-tool-${PV}")
then handle this automatically. Also handle when it changes to match the
default S value (i.e. "${WORKDIR}/${BP}") in which case we just drop
setting S in the recipe.
Fixes [YOCTO #10939].
(From OE-Core rev: d29881a652bf03627d257a1eac5f02ec17315b8b)
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>
Give the user a little more insight into what's being done.
(From OE-Core rev: 9cf2089bd22b9fc4eb0eec8d4924e44519412dad)
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>
devtool upgrade did not properly handle setting SRC_URI checksums for
recipes that use named SRC_URI entries and also use those names in the
SRC_URI checksums. A further complication was where the name contained
an expression that changed with the version e.g. ${PV} (probably quite
rare, but the dnsmasq recipe in meta-networking is currently one such
recipe.) All of these are now handled properly.
Additionally, drop the _get_checksums() function that wasn't being
called from anywhere in the code.
Note that this now turns nowrap_vars in recipeutils.py to be a list of
regexes, hence things such as [ and ] need to be appropriately escaped.
(From OE-Core rev: c914a5e1ad6d96e316746222e5d42f2ba9110060)
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>
devtool finish will check if the destination layer is part of
bblayers.conf so that we avoid the user getting confused about the
recipe vanishing from their configuration if it isn't. devtool finish
also accepts a path underneath a layer so that you have a bit
more control over where it ends up. However if you used a path
underneath a layer then it wasn't converting this to the base of the
layer before checking it against BBLAYERS, thus the warning was being
shown erroneously in that case.
(From OE-Core rev: ab1b8d55e551fea3e8656aab7a786d1bfec62d0f)
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 the git repository for a recipe in the workspace has uncommitted
changes in it then it's possible that the user has forgotten to commit
something, so check and exit if there are any. Provide a -f/--force
option to continue in the case where the uncommitted changes aren't
needed.
Separately, if the repository is in the middle of a rebase or git am /
apply then error out (without the opportunity to force) since the user
really needs to sort this out before finishing.
(From OE-Core rev: bfebd18982c0c82ef2da63ec8f22175c93b2e308)
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 S points to a subdirectory of the source rather than the "base" of
the source tree then print that rather than the subdirectory path when
telling the user they need to remove the source tree, since that is the
directory that they will need to remove.
(From OE-Core rev: 9e8808099046478e98c6cf1903dc6787d69132fc)
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>
After some reconsideration I think it's a bit annoying for users to be
forced to use an option to work with recipes where the file isn't in the
workspace, so let's just have these commands check the workspace first
for the recipe, and if it isn't there then load the cache and get it
that way.
(From OE-Core rev: 46683c61069a386658676a79d797062404bf1140)
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>
* Show a warning in devtool upgrade if the version is less than the
current version suggesting that the user may need to bump PE in the
recipe
* Show a warning in devtool add and devtool upgrade if the version looks
like a pre-release version suggesting using a version number that
won't mess up the progression when you come to upgrade to the final
release version.
(From OE-Core rev: 92c4d9be9ed365c449ea1ac5a18ddb15e4a36b2d)
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 S points to a subdirectory of the source rather than the "base" of
the source tree then we weren't handling the oe-local-files directory
properly - it got extracted to the base of the tree but devtool
update-recipe and devtool finish assumed it would be under S which would
be the subdirectory, thus it would be missing and devtool would assume
the files had been deleted and remove them from the recipe. Record the
base of the source tree in the bbappend and read it into the in-memory
workspace so we can use that to find out where oe-local-files should be
found.
(From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc)
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>
When devtool upgrade is upgrading to a new version where the source is
fetched as an archive (e.g. a tarball), we create a single commit in the
git repository that is the upgrade from the old version to the new. We
do this by extracting the old source, committing it, deleting all files,
copying in the new files, running git add on each new/changed/deleted
file, and then committing the result. When a lot of files have changed
in an upgrade (such as QEMU 2.8.1.1 -> 2.10.0) the penultimate step of
running git add it can take quite a long time; in order to reduce this
and show some feedback to the user, run git add with batches of 100
files at once and also show a progress bar. In a local test with the
aforementioned QEMU upgrade it took the time down from over 7 minutes
down to about 13 seconds.
Fixes [YOCTO #11948].
(From OE-Core rev: 8b184f6c874b60324ee107af53853687173d3434)
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 versions of git older than 2.0, "git add" on a deleted file (i.e.
in this case a file that was removed between versions) will not add the
delete to be committed by default, with the result that the rebase of
patches on top of the new branch will fail. We need to use the -A
option in order to force that for older git versions.
(From OE-Core rev: c7f4c9f050c11c0de7fcf5badcc19a8fbc6428cf)
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>
It appears that when fixing the signature unlocking in OE-Core commit
4e9a0be32fc30fb87d65da7cd1a4015c99533aff I swapped the parameters here
and did not test it within the eSDK (it does nothing outside of the
eSDK) resulting in a TypeError when devtool upgrade was used in the
eSDK. Swap the parameters around to the correct ordering.
Fixes [YOCTO #12285].
(From OE-Core rev: 05e2c4ada7083f40866846a21fe76c852f1dfefe)
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 SRCREV contains a variable reference, any devtool command that
would try to update it would fail. E.g., if SRCREV = "R${PV}", then
devtool finish without having committed any changes would fail with:
oe.patch.CmdError: Command Error: 'sh -c 'git format-patch R${PV} -o
/tmp/oepatchb_doareb -- .'' exited with 0 Output:
fatal: bad revision 'R'
(From OE-Core rev: 094499c819722ad698ccb64ec65dd439b211c31c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Search made with the following regex: getVar ?\((.*), True\).
(From OE-Core rev: b848c3cb495905605283c57c79f2ed8ca17758db)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alongside reworking the way devtool extracts source, we now need to
ensure that within the extensible SDK where task signatures are locked,
the signatures of the tasks for the recipes being worked on get unlocked
at the right time or otherwise we'll now get taskhash mismatches when
running devtool modify on a recipe that was included in the eSDK such as
the kernel (due to a separate bug). The existing mechanism for
auto-unlocking recipes was a little weak and was happening too late, so
I've reimplemented it so that:
(a) it gets triggered immediately when the recipe/append is created
(b) we avoid writing to the unlocked signatures file unnecessarily
(since it's a global configuration file) and
(c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES
to avoid unnecessary reparses every time we perform one of the
devtool operations that does need to change this list.
Fixes [YOCTO #11883] (not the underlying cause, but this manifestation
of the issue).
(From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since it was first implemented, devtool's source extraction (as used by
the devtool modify, extract and upgrade subcommands) ignored other recipe
dependencies - so for example if you ran devtool modify on a recipe that
fetches from svn or is compressed using xz then it would fail if those
dependencies hadn't been built first. Now that we can execute tasks in
the normal way (i.e. tinfoil.build_targets()) then we can rework it to
use that. This is slightly tricky in that the source extraction needs to
insert some logic in between tasks; luckily we can use a helper class
that conditionally adds prefuncs to make that possible.
Some side-effects / aspects of this change worth noting:
* Operations are a little slower because we have to go through the task
dependency graph generation and other startup processing. There's not
really any way to avoid this though.
* devtool extract didn't used to require a workspace, now it does
because it needs to create a temporary bbappend for the recipe. (As
with other commands the workspace be created on the fly if it doesn't
already exist.)
* I want any existing sysroot files and stamps to be left alone during
extraction since we are running the tasks off to the side, and
especially devtool extract should be able to be used without touching
these. However, this was hampered by the automatic removal process in
sstate.bbclass triggered by bb.event.ReachableStamps when the task
signatures change, thus I had to introduce a way to disable this
removal on a per-recipe basis (we still want it to function for any
dependencies that we aren't working on). To implement this I elected
to use a file written to tmp/sstate-control which gets deleted
automatically after reading so that there's less chance of stale files
affecting future sessions. I could have used a variable but this would
have needed to be whitelisted and I'd have to have poked its value in
using the setVariable command.
Fixes [YOCTO #11198].
(From OE-Core rev: 830dbd66992cbb9e731b48d56fddf8f220349666)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe added with "devtool add" requires to be able to take precedence on recipes
previously defined with PREFERRED_PROVIDER.
By adding the parameter "--provides" to "devtool add" it is possible to specify
an element to be provided by the recipe. A devtool recipe can override a previous
PREFERRED_PROVIDER using the layer configuration file in the workspace.
E.g.
devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl
[YOCTO #10415]
(From OE-Core rev: adeea2fe6895898a5e6006e798898f0f5dabd890)
Signed-off-by: Juan M Cruz Alcaraz <juan.m.cruz.alcaraz@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If user.name or user.email haven't been set then git rebase can't really
work properly. Check that the user has set these and error out if not.
(Elsewhere we are relying on OE's git patch functionality which forces
a dummy OE value - that's OK there as it's completely under OE's control
and therefore it's OK for a dummy OE user to be the committer, but here
the rebase may require intervention so it's reasonable to have the
user's actual name and email on the operation.)
Fixes [YOCTO #11947].
(From OE-Core rev: 129a3be07e272013be2db17552c13b4d8cc2cf6e)
(From OE-Core rev: 802829f1c38d8c5eee11ba1d9ddd37cf02597f6e)
Signed-off-by: paul <paul@peggleto-mobl.ger.corp.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sorted entries are easier to read.
(From OE-Core rev: d0a123ec564f6d36977e472f8bc63f9c050ee616)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At the moment when fetching source from a git repository you have to
know that you can specify the revision and branch in the URL with
';rev=' and ';branch=' respectively, and you can also get thrown off by
the shell splitting on the ; character if you forget to surround the URL
in quotes. Add explicit -S/--srcrev and -B/--srcbranch options
(consistent with devtool upgrade) to make this easier for the user to
discover and use. (The rev and branch URL parameters will continue to
work, however.)
(From OE-Core rev: 2d86cac853d6daa496c0315a5cb0662ebf1165b0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-Core commit 5a16b3c804c5eca331a1c08a7ce31a54909af105 attempted to use
the same function to get the path to a recipe as the new "find-recipe"
command it implemented, except that cannot work because (a) it didn't
return anything and (b) event if it had tried, a command function can
only return an exit code and we don't want that for find-recipe if it
succeeded. Split out a separate reusable function for both commands.
(From OE-Core rev: d5191840212adbf480961ba6fc68e1ab17e5a77a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're upgrading a recipe that appends additional patches for, say,
class-native, and we're just upgrading the target variant, then when we
copied the recipe into the workspace we skipped copying the additional patches
for the native variant. This caused warnings because the workspace
recipe is preferred. Look at SRC_URI for all variants when copying files
to work around this.
More work is needed to make it easier to work with recipes that use
BBCLASSEXTEND where you need to build more than one variant at once, but
this at least fixes the immediate ugliness.
(From OE-Core rev: 56bf5e93358187e31160d7893f57906bb3dc7ad7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If your BBLAYERS has non-absolute paths in it (e.g.
"${COREBASE}/../something") then none of the paths matched in
copy_recipe_files() with the result that no files got copied and you
ended up with an error later on because the recipe file couldn't be
found at the destination. Fix this as well as adding an explicit check
to see if no files got copied - error out earlier if so.
Fixes [YOCTO #10981].
(From OE-Core rev: 3861486ad06f90c8644ebab119bbc5ddb9e693ca)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patches that we identify as having been "deleted" (i.e. patches in
SRC_URI that no longer appear in the git tree) need to be dropped even
if we're updating in srcrev mode. This fixes the case where HEAD of the
git tree is valid upstream (i.e. no extra commits), but there are
patches left over in the recipe, e.g. when we do devtool upgrade and
then all of the commits rebased on top of the new branch get skipped.
Fixes [YOCTO #11972].
(From OE-Core rev: 350f83dc1e317aeb93539f13966caca6d894f569)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New devtool deploy-target option --strip which enables deploying
stripped binaries, saving some space on target.
* Copies the files of ${D} into a new directory and strips them in place
* Used oe.package.strip_execs for stripping directory
* Added devtool.conf option "strip" for changing default behavior
Config example:
[Deploy]
strip = true
[YOCTO #11227]
(From OE-Core rev: 7f10c5118793da6ded59ae6e60e796152dbd7ca3)
Signed-off-by: Tobias Hagelborn <tobiasha@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Takes a tar archive created by 'devtool export' and imports (untars) it
into the workspace. Currently the whole tar archive is imported, there
is no way to limit what is imported.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510
[YOCTO #10510]
(From OE-Core rev: 2de8ba89ef10fefcc97246dfeb4b8d1e48ee8232)
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>
In case the proposed md5sum to be appended to the .devtool_md5 file
is already present, do not append it.
(From OE-Core rev: f958c5cba3b0d24ca696b2b707857009c9a7b5b8)
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>
By default, exports the whole workspace (all recipes) including the source code.
User can also limit what is exported with --included/--excluded flags. As
a result of this operation, a tar archive containing only workspace metadata
and its corresponding source code is created, which can be properly imported
with 'devtool import'.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510
[YOCTO #10510]
(From OE-Core rev: f9bc3b5101b554a72298266519dbdd1497f262a6)
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>
When devtool upgrade is run on a recipe with revision specified
that is not on master branch, and branch isn't set by --srcbranch or -B,
then we should get the correct branch and append the branch to the URL.
If the revision was found on multiple branches, we will display error
to inform user to provide a correct branch and exit.
[YOCTO #11484]
(From OE-Core rev: 29ced7387a92aed17b7fe93b1654790a981734c1)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 4657bc9d165e51981e034e73e7b92552e873eef7 replaced the git pull logic with
the git fetch + git reset --hard combo, but resetting to HEAD does not really
pull in new commits from remote... Replace with resetting to the upstream branch
instead.
(From OE-Core rev: 0dcdb146f59a184419bffd4f24cdf8343a43c0ea)
Signed-off-by: Andrea Galbusera <gizero@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* If an error is logged while executing a task, we need to ensure we
exit instead of assuming everything went OK.
* If we receive CookerExit, the server is shutting down and we need to
stop waiting for events and probably exit (knotty does this). This
will occur if an exception or bb.fatal() happens during an event
handler.
This fixes a couple of issues highlighted when using devtool upgrade or
modify on a non-supported recipe with intel-iot-refkit together with
bitbake master, but I'd be very surprised if it were hard to reproduce
in other scenarios.
(From OE-Core rev: 65e644368fc9c294af96906528ee0cf30305e0a6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we have provide an option to manually enable PREMIRRORS and MIRRORS
in recipetool, we need to make sure devtool is having the same options
as devtool uses recipetool in creating new recipes.
(From OE-Core rev: 198bddeb928a318c3ad168bcb4f83b5cd9a604fb)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool find-recipe will prints out the path to the recipe
in a workspace.
This subcommand can also help to find recipe outside of
current workspace using "-a" or "--any-recipe" option.
This enhancement helps developer to get the recipe path
when working with devtool.
[YOCTO #11434]
(From OE-Core rev: 5a16b3c804c5eca331a1c08a7ce31a54909af105)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
logger was not defined in scriptutils.py based on the
observation in python traceback.
Traceback (most recent call last):
File "/workdir/poky/scripts/devtool", line 351, in <module>
ret = main()
File "/workdir/poky/scripts/devtool", line 338, in main
ret = args.func(args, config, basepath, workspace)
File "/workdir/poky/scripts/lib/devtool/utilcmds.py", line 55, in
edit_recipe
return scriptutils.run_editor(find_recipe(args, config, basepath,
workspace))
File "/workdir/poky/scripts/lib/scriptutils.py", line 141, in
run_editor
logger.error("Execution of '%s' failed: %s" % (editor, exc))
NameError: name 'logger' is not defined
We pass in logger as parameter to run_editor() from where it has
been called (devtool/utilcmds.py and recipetool/newappend.py),
which both modules already has logger setup.
(From OE-Core rev: 21f04b61973dd9029f0e6bff5445e31cd762bf32)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids test failures like:
INFO - ======================================================================
INFO - FAIL [1.755s]: test_devtool_layer_plugins (devtool.DevtoolTests)
INFO - ----------------------------------------------------------------------
INFO - Traceback (most recent call last):
File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
return func(*args, **kwargs)
File "/media/build1/poky/meta/lib/oeqa/selftest/cases/devtool.py", line 1354, in test_devtool_layer_plugins
self.assertEqual(result.output, s[::-1])
AssertionError: "NOTE: Starting bitbake server...\noY senu[36 chars]rciM" != "oY senuZ s'enoynA morF tiforP oN edaM tfosorciM"
- NOTE: Starting bitbake server...
oY senuZ s'enoynA morF tiforP oN edaM tfosorciM
INFO - ----------------------------------------------------------------------
since there is corruption in the output. Setting the logging up before
calling tinfoil.prepare() resolves this.
(From OE-Core rev: 3c479fb17ae4d3e7e5f0889af0f68257ef66475c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Across devtool and recipetool we had an ugly set of code for ensuring
that we can call an npm binary, and much of that ugliness was a result
of not being able to run build tasks when tinfoil was active - if
recipetool found that npm was required and we didn't know beforehand
(e.g. we're fetching from a plain git repository as opposed to an npm://
URL where it's obvious) then it had to exit and return a special result
code, so that devtool knew it needed to build nodejs-native and then
call recipetool again. Now that we are using real build tasks to fetch
and unpack, we can drop most of this and move the code to the one place
where it's still needed (i.e. create_npm where we potentially have to
deal with node.js code in a plain source repository).
(From OE-Core rev: 8450de16ddb02d863204b411a94c6d84e0f88817)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have the ability to run the tasks in a more standard context
through tinfoil, change recipetool's fetching code to use that to fetch
files using it. This has the major advantage that any dependencies of
do_fetch and do_unpack (e.g. for subversion or npm) will be handled
automatically. This also has the beneficial side-effect of fixing a
recent regression that prevented this fetch operation from working with
memory resident bitbake.
Also fix devtool's usage of fetch_uri() at the same time so that we can
completely replace it.
Fixes [YOCTO #11710].
(From OE-Core rev: 9a47a6690052ef943c0d4760630ee630fb012153)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When extracting linux-yocto kernel source, we don't need to dance around
shutting down and starting up tinfoil anymore, we can just execute the
tasks as needed when needed using tinfoil's new build_targets()
function. This allows us to tidy up the code structure a bit.
(From OE-Core rev: 5c7f5031023fb74b5f2f26d6b3c829981f2f54d2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If for any reason the parse_recipe fail in extract command
the process gets locked because Cooker is expecting the
finish event by tinfoil.
For example:
$ devtool extract remake /tmp/remake
ERROR: remake is unavailable:
remake was skipped: PREFERRED_PROVIDER_virtual/make set to make, not remake
(From OE-Core rev: 2c0062b59178fa668b26487b6d2f1e81a0d868e0)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The remote script is run with `set -e`, so doing rm without -f on a
$file that is already gone will exit the whole script, failing any
redeployment. Assume a use case where packages sometimes produces
certain test binaries stored on volatile media (tmpfs), and where the
system is occasionally rebooted.
(From OE-Core rev: db54c9a22a9b66c673df8e836de5e47fc9edda0b)
Signed-off-by: Daniel Lublin <daniel@lublin.se>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Either both or none of the paths must be passed through
os.path.abspath or things like 'A//B', 'A/./B/', and 'A/B/' in S will
cause unintentional mismatches even when B = "${S}".
Using os.path.abspath for both seems more likely to be correct as that
will also handle the case where ${B} != ${S} but the abspaths are
equal.
(From OE-Core rev: 061f2aab40fecbfe0dcb928baa95d6b3a6b45eed)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
find may be provided by busybox, which might be compiled without support
for -exec.
(From OE-Core rev: 404e8e3661469175e1ea087ebfaf3a7867bf4df2)
Signed-off-by: Daniel Lublin <daniel@lublin.se>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Perf is a tool build from the kernel source, which is normally available
in /work-shared/..., but when devtool is used to modify the kernel
source code, perf is not buildable since it gets an error about being unable
to add a depends to a non-exisit task do_patch.
This patch removes do_patch from the SRCTREECOVEREDTASKS and creates an empty
do_patch task to enable the VarFlags code to have someplace to attach depends
information to.
[YOCT #11120]
(From OE-Core rev: 86c793595e560e7bc52e3cd2a2752746e6adcb76)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a non-existent event - we already have the actual
bb.build.TaskSucceeded further down in the list hence why it wasn't
noticed earlier.
(From OE-Core rev: 4e059a5ceb6f44401154e89e37f56de1d664a7cb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a task such as do_fetch fails when we're extracting source for a
recipe (within devtool modify / upgrade / extract / sync) then we should
naturally stop processing instead of blundering on; in order to do that
we need to be listening for the TaskFailed event. Thanks to Richard
Purdie for noticing and fixing this.
(From OE-Core rev: 9174b845bf6a6be7753bf6b921959b1f3f2dcbc0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of the other extract-based commands have this option but oddly I
left it out for modify - I guess because if I was debugging an issue here
I just used devtool extract to do so, but there's no reason why we can't
have it here and it is useful.
(From OE-Core rev: 98fbc46e1a51237213bd7825a922389d3ab2ad9b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If recipetool returns with exit code 14 this means devtool needs to
build nodejs-native and then call it again. If recipetool returns exit
code 14 again then clearly something has gone wrong and we should just
quit with an error.
(From OE-Core rev: 8d7cced6e06d7c2037f5ab75ac859f501129532e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change over to recipe specific sysroots means that we can no longer
get a known location simply from configuration for the npm binary - we
need to get the recipe sysroot for nodejs-native, look there for npm if
we need to check it's present, and add that to PATH when calling out to
npm. Unfortunately this means anywhere we need to get that path we have
to have parsed all recipes, otherwise we have no reliable way of
resolving nodejs-native. Thus we have to change recipetool create to
always parse all recipes (the structure of the code does not allow us to
do this conditionally).
In the worst case, if npm hasn't already been added to its own sysroot
and we are fetching from a source repository rather than an npm
registry, this gets a bit ugly because we end up parsing recipes three
times:
1) recipetool startup, which then fetches the code and determines it's
a node.js module, finds that npm isn't available and then exits with
a specific error to tell devtool it needs to build npm
2) when we invoke bitbake -c addto_recipe_sysroot nodejs-native
3) when we re-invoke recipetool
This code is badly in need of refactoring, but now is unfortunately not
the time to do that, so we're going to have to live with this ugliness
for now.
Fixes [YOCTO #10992].
(From OE-Core rev: acfdbd796c99882b8586023c8c6b848716105c8d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool/runqemu.py was relying on STAGING_BINDIR_NATIVE to find the host
tools it needed like qemu-system-<arch>. In the post RSS world, this no
longer exists. This patch points it to
{STAGING_DIR}/{BUILD_ARCH}/{bindir_native}.
[YOCTO #11223]
(From OE-Core rev: 1910f9e9336bfedc8278a3bc02e7e7f934a4fc86)
Signed-off-by: brian avery <brian.avery@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When devtool writes to the kconfig fragment, it writes the output of
the diff command returned from pipe.communicate(). This function
returns binary objects. We should open the kconfig fragment file in
binary mode if we expect to write binary objects to it.
[YOCTO #11171]
(From OE-Core rev: 72bec63ab0e78753fb6ed1794d11beef9485c014)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the tinfoil2 refactoring, if an error occurred during parsing, we
were showing a traceback and not correctly exiting (since we weren't
calling shutdown()). Fix both of these issues.
(From OE-Core rev: 18304036e1b513fd12c049dbf549ba75c503ed84)
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>
Web applications built using e.g. angular2, usually requires that the
packages in devDependencies are available.
Thus, add an option '--fetch-dev' to both devtool add and recipetool, to
add npm packages in devDependencies to DEPENDS.
(From OE-Core rev: f246f820d53b459596fde6758a09f7a0d7db7c4c)
Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After running sdk-install we need to ensure that the standalone sysroots are
updated as done when the eSDK is originally built. Add such a call so this
happens automatically and the envrionment scripts in the SDK work correctly
after updates.
(From OE-Core rev: 4f422071d6f9a074986f399d9e648977bd2e0a68)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable using, e.g. host port 2222 for connection to qemu target.
Defaults to 22 for standard ssh/scp port.
[YOCTO #11079]
(From OE-Core rev: a2bfa2cc9ee19f617f7d3b6447896e45eb855d2e)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
upgrade.py imports oe.recipeutils in meta/lib/ but path to oe.recipeutils
is not provided. This fails populate_sdk_ext.
(From OE-Core rev: 5f140359f859fea9cfe8c8d9c9584bceec875adb)
Signed-off-by: Luck Hoang <huyht1205@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the move to tinfoil2, the behaviour when parsing failed has changed
a bit - exceptions are now raised, so handle these appropriately.
Specifically when if parsing the recipe created when running devtool add
fails, rename it to .bb.parsefailed so that the user can run bitbake
afterwards without parsing being interrupted.
(From OE-Core rev: b9592bd3c1ab2155b9f62d18ce593b9c88eff279)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When extracting source for a recipe within devtool (for extract, modify
or upgrade) We need to redirect WORKDIR, STAMPS_DIR etc. under a
temporary directory so that:
(a) we pick up all files that get unpacked to the WORKDIR, and
(b) we don't disturb the existing build
However, with recipe-specific sysroots the sysroots for the recipe will
be prepared under WORKDIR, and if we used the system temporary directory
i.e. usually /tmp) as used by mkdtemp by default, then our attempts to
hardlink files into the recipe-specific sysroots will fail on systems
where /tmp is a different filesystem, and we'd have to fall back to
copying the files which is a waste of time. Put the temp directory under
the WORKDIR to prevent that from being a problem.
(From OE-Core rev: e10a973cd9390eacb13bdb99693a0622bd3695f5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
[RP: Add needed mkdirhier call]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:
d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')
which I've corrected (they happend to work by luck).
(From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using devtool modify on the kernel, we have to do a bit of a dance
with tinfoil instances because we only find out that we're working on a
kernel recipe after tinfoil is initialised, but then we need to build
kern-tools-native which we're doing just by running bitbake directly.
With the tinfoil2 changes, a datastore for the recipe that we were
keeping around across the opening and closing of tinfoil is no longer
able to be used. Re-parse the recipe to avoid this problem.
(In future this whole thing will be able to be done in the same tinfoil
instance thanks to tinfoil2, but that refactoring is yet to be done.)
(From OE-Core rev: 06127d0115ba449bf04e2579cd1010065e0ed6e3)
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>
Using the setVariable commands here followed by buildFile will result in
"basehash mismatch" errors, and that's expected since we are deviating
*at runtime* from what was previously seen by changing these variable
values. Set BB_HASH_IGNORE_MISMATCH to turn off the errors.
(From OE-Core rev: b0169796f294bbec0397b7eae86454a46b68cdc5)
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>
Extracting the source for a recipe (as used by devtool's extract, modify
and upgrade subcommands) requires us to run do_fetch, do_unpack,
do_patch and any tasks that the recipe has inserted inbetween, and do so
with a modified datastore primarily so that we can redirect WORKDIR and
STAMPS_DIR in order to have the files written out to a place of our
choosing and avoid stamping the tasks as having executed in a real build
context respectively. However, this all gets much more difficult when in
memres mode since we can't call internal functions such as
bb.build.exec_func() directly - instead we need to execute the tasks on
the server. To do this we use the buildFile command which already exists
for the purpose of supporting bitbake -b, and setVariable commands to
set up the appropriate datastore.
(I did look at passing the modified datastore to the buildFile command
instead of using setVar() on the main datastore, however its use of
databuilder makes that very difficult, and we'd also need a different
method of getting the changes in the datastore over to the worker as
well.)
(From OE-Core rev: eb63b5339014fc72ba4829714e0a96a98e135ee2)
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 PATCHTOOL is "git", and PATCH_COMMIT_FUNCTIONS is set to "1", for
additional tasks between do_unpack and do_patch, make a git commit. This
logic was previously implemented in devtool itself, but it makes more
sense for it to be implemented in the patch class since that's where the
rest of the logic is for this (or in lib/oe/patch.py). It also makes
it possible for this to work with tinfoil2.
(From OE-Core rev: f24f59ea1d8bc335ea8576f6a346d0935f4a3548)
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>
Use Tinfoil.parse_recipe_file() and Tinfoil.parse_recipe() instead of
the recipeutils equivalents, and replace any local duplicate
implementations. This not only tidies up the code but also allows these
calls to work in memres mode.
(From OE-Core rev: f13b56266ee96dfab65a3a7db50e8051aa9f071a)
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>
