[YOCTO #15162]
when doing devtool modify, sources are extracted into a devtool
temporary workdir. The main source is moved inside
build/workspace/sources/${BPN}/ and local files are moved inside
build/workspace/sources/${BPN}/oe-local-files. Secondary sources are
currently not handled and are lost.
Here is the output of devtool modify/build on bzip2 recipe:
NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None)
ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest
| sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
| ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory
| WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
| #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189
| #2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158
| #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226
ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
externalsrc class modify SRC_URI to keep only:
* 'file', 'npmsw' and 'crate' sources
* url with type parameter matching 'kmeta' or 'git-dependency'
So by forcing to add type='git-dependency' on secondary sources, we
ensure that when building the recipe, the secondary sources can be
unpacked into WORKDIR.
This allows recipes containing several sources to be built under a
devtool context, but it has some limitations:
* user would not be able to generate patches for the secondary sources
* type="git-dependency" is added for secondary sources even on non git
sources, so we may want to rename this parameter
(From OE-Core rev: cfd5ee890163a3d975093359016dda104e7b71df)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Root Cause:
initial_revs is an empty dictionary and do not have "." key.
Traceback (most recent call last):
File "scripts/devtool", line 349, in <module>
ret = main()
File "scripts/devtool", line 336, in main
ret = args.func(args, config, basepath, workspace)
File "scripts/lib/devtool/standard.py", line 922, in modify
if not initial_revs["."]:
KeyError: '.'
Solution:
check key exists, then get its value.
(From OE-Core rev: fb0db5c48abb4d56233a175fdd349d18b972e452)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'devtool check-upgrade-status' is for reporting upgradable
status for recipes. The output should always be printed out. So
we should just use 'print' instead of 'logger.info' as the latter
will be suppressed if '-q' parameter is supplied to devtool.
(From OE-Core rev: 2c7bf9c8a833bec13a1ebabdce30933cbe691108)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the following error when running `devtool modify` on a
recipe that has a menuconfig task, but does not have
KCONFIG_CONFIG_ENABLE_MENUCONFIG set.
.../temp/run.do_configure.4163366: line 152:
${@ oe.types.boolean('${KCONFIG_CONFIG_ENABLE_MENUCONFIG}') }: bad substitution
WARNING: .../temp/run.do_configure.4163366:152 exit 1 from
'[ ${@ oe.types.boolean('${KCONFIG_CONFIG_ENABLE_MENUCONFIG}') } = True ]'
(From OE-Core rev: e87e6fa84a0c4b5ac8e736dc62f6e08390ba2436)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the following error when using --no-extract, introduced in
commit 900129cbdf (devtool: add support for git submodules):
Traceback (most recent call last):
File ".../scripts/devtool", line 349, in <module>
ret = main()
File ".../scripts/devtool", line 336, in main
ret = args.func(args, config, basepath, workspace)
File ".../scripts/lib/devtool/standard.py", line 995, in modify
for commit in commits[name]:
KeyError: '.'
(From OE-Core rev: 6a44fb10ef4b90ee24f470362007d56183abc593)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In addition to updating the sha256sum and removing the md5sum, update
all other existing checksums. If the only existing checksum is md5sum,
then replace it with the default expected checksums (currently only
sha256sum).
(From OE-Core rev: 8ea8827ee49b7f0443b1c4bd47d1344a689d73a3)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Today, we can use devtool/recipetool to create recipes for python projects
using the github url or the direct release tarball of the project, but the
create_buildsys_python plugin doesn't support the pypi class, since we cannot
know from the extracted source if the package is available on pypi or not.
By implementing the new optional process_url callback, we can detect
that the url is a pypi one (i.e 'https://pypi.org/project/<package>')
and retrieve the release tarball location.
Also detect if the url points to a release tarball hosted on
"files.pythonhosted.iorg" (i.e https://files.pythonhosted.org/packages/...)
In both cases, adds the pypi class, remove 'S' and 'SRC_URIxxx'
variables from the created recipe as they will be handled by the pypi class
and add the PYPI_PACKAGE variable
This helps to produce cleaner recipes when package is hosted on pypi.
If the url points to a github url or a release tarball not coming from
"files.pythonhosted.org", the created recipe is the same as before.
One can also use the newly added "--no-pypi" switch to NOT inherit
from pypi class on matching url, to keep legacy behaviour.
To create a recipe for a pypi package, one can now use one of the
new following syntax (using recipetool create / devtool add):
* recipetool create https://pypi.org/project/<package>
* recipetool create https://pypi.org/project/<package>/<version>
* recipetool create https://pypi.org/project/<package> --version <version>
or the old syntax:
* recipetool create https://files.pythonhosted.org/packages/<...>
(From OE-Core rev: 097a43846cd99a7d74d004efc57f583ce78970a4)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding the support of submodules required a lot of changes on the
internal data structures:
* initial_rev/startcommit used as a starting point for looking at new
/ updated commits was replaced by a dictionary where the keys are the
submodule name ("." for main repo) and the values are the
initial_rev/startcommit
* the extractPatches function now extracts patch for the main repo and
for all submodules and stores them in a hierarchical way describing the
submodule path
* store initial_rev/commit also for all submodules inside the recipe
bbappend file
* _export_patches now returns dictionaries that contains the 'patchdir'
parameter (if any). This parameter is used to add the correct
'patchdir=' parameter on the recipe
Also, recipe can extract a secondary git tree inside the workdir.
By default, at the end of the do_patch function, there is a hook in
devtool that commits everything that was modified to have a clean
repository. It uses the command: "git add .; git commit ..."
The issue here is that, it adds the secondary git tree as a submodule
but in a wrong way. Doing "git add <git dir>" declares a submodule but do
not adds a url associated to it, and all following "git submodule foreach"
commands will fail.
So detect that a git tree was extracted inside S and correctly add it
using "git submodule add <url> <path>", so that it will be considered as a
regular git submodule
(From OE-Core rev: 900129cbdf25297a42ab5dbd02d1adbea405c935)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the case of a repository with submodules, we need to add the
"devtool-base" and "devtool-patched" tag on all submodules in order to
properly detect the added/removed/modified patches
(From OE-Core rev: 241da68805d177d4ec4b302c8a997645cc645286)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When specifying --mode / -m srcrev with devtool finish/update-recipe on
recipes that are not fetched from a SCM repository we get the following
error:
Traceback (most recent call last):
[..]
File "<...>/poky/meta/lib/oe/patch.py", line 49, in runcmd
raise CmdError(cmd, exitstatus >> 8, "stdout: %s\nstderr: %s" % (stdout, stderr))
oe.patch.CmdError: Command Error: 'sh -c 'git format-patch --no-signature --no-numbered INVALID -o /tmp/oepatchbj7pfmzj -- .'' exited with 0 Output:
stdout:
stderr: fatal: bad revision 'INVALID'
Fix this by adding a check and abort with a proper error message.
(From OE-Core rev: 5b77f60e85d07921ae5e808daa1fd7d8c3dc40ea)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running devtool update-recipe with --mode=srcrev AND --append switch
in dry-run, we get the following error:
Traceback (most recent call last):
[...]
Exception: destpath should be set here
Fix this by removing a misplaced else statement in _update_recipe_srcrev
(From OE-Core rev: 85ba125703d5b442133fd7c470b915460ee68ac9)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #15222]
In some situations its more practical to keep git configuration
at `/etc/gitconfig` instead of `$HOME/.gitconfig` (e.g., when mounting
git configuration into a docker container).
This change makes `devtool upgrade` consider any available
git configuration instead of only checking `--global`.
(From OE-Core rev: 30a9f7de45050c8bac49d4b37419cc2e067a75fa)
Signed-off-by: Marcus Flyckt <marcus.flyckt@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake has changed to require notification when metadata changes in the middle of tinfoil
sessions. Add the required function calls at the places metadata is changed.
(From OE-Core rev: e5574163ab49a8f51b2b34fd37acfd1cad9b7595)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop some unused imports.
(From OE-Core rev: 432446ef402ff42fe0c90172b77376fa5981524a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This can happen if running unpack task produces unrelated files and directories
(e.g. if recipe_qa or other tasks run); in this case it's better to stop, rather
than allow devtool to continue and error out much later with a message that has
nothing to do with where the problem originated.
The idea here was to handle tarballs that don't contain a top level directory and thus
the source tree is one level up; this basically never happens, and if it does we
should find a less brittle way to handle such tarballs.
(From OE-Core rev: b25e922b271794906b22450c7e6cc18fcab51ff8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The immediate reason is that the task is sstate enabled, and due
to the way devtool sets up source extraction this causes bogus
values to appear in tmp/sstate-control/index-* files.
Also, recipe_qa may contain hard failures in the future, and it
would be counterproductive for the failures to prevent devtool
workflows (which may perhaps be about fixing the failure).
An alternative would have been to not insert recipe_qa task before
fetch task, but that would greatly delay the checks in larger
bitbake builds, and it's better to run them as early as possible.
(From OE-Core rev: 6f9db3f8de3dca9b0c87382561c70857d5b39e0f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool crashes when running "update-recipe" and append changes on the recipe.
"$ devtool update-recipe -a <layer> <recipe>"
Traceback (most recent call last):
...
File "/ovss/ovss_quanta/poky/scripts/lib/devtool/standard.py", line 1636, in srcuri_entry
return 'file://%s%s' % (basepath, paramstr)
^^^^^^^^
NameError: cannot access free variable 'basepath' where it is not associated with a value in enclosing scope
The input variable 'fname' should have the same meaning as the variable 'basepath'.
Modify the 'fname' to 'basepath' and solve the issue.
(From OE-Core rev: c3231756bbc2cb5641204414ad3670d7f8607ed3)
Signed-off-by: Charlie Wu <chiachiwu@google.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, uboot do_menuconfig task is breaking when UBOOT_CONFIG is
chosen rather than UBOOT_MACHINE, it simply fails with the following
errors:
| make: *** No rule to make target 'menuconfig'. Stio.
| Command failed.
| Press any key to continue...
this is due to the work directory of do_menuconfig is set to ${B} but
not ${B}/$config.
We should distinguish two situations:
1) When there is only one config item in UBOOT_CONFIG, do_menuconfig
should work just like how it works for UBOOT_MACHINE.
2) When there are multiple config items in UBOOT_CONFIG, do_menuconfig
should print out some information saying it's not supported other
than just failing.
This patch mainly aims to fix that by introducing a extra variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG, it would be set to 'false' for
situation 2), and when it's set to 'true', then set
KCONFIG_CONFIG_ROOTDIR correctly in uboot-config.bbclass to let
do_menuconfig task work.
DEVTOOL_DISABLE_MENUCONFIG could be replaced by this new variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG.
(From OE-Core rev: f9e834e317880cf47dbb4f8285bc36d743beae5e)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If it exists, there is no need to delete it, and if it does not,
devtool prints an ugly traceback.
(From OE-Core rev: af82e59e8f08369aabd5fa6eb43022982d4e59a7)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
So that patch fuzz issues can actually be fixed,
as extracting source with 'devtool modify' is the first step
for that.
(From OE-Core rev: 7067abd31d9dd4b98ec70c1c7effbe2904797cd1)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* True is default since 2016 and most layers were already updated
not to pass this parameter where not necessary, e.g. oe-core was
updated couple times, first in:
https://git.openembedded.org/openembedded-core/commit/?id=7c552996597faaee2fbee185b250c0ee30ea3b5f
Updated with the same regexp as later oe-core update:
https://git.openembedded.org/openembedded-core/commit/?id=9f551d588693328e4d99d33be94f26684eafcaba
with small modification to replace not only d.getVar, but also data.getVar as in e.g.:
e.data.getVar('ERR_REPORT_USERNAME', True)
and for getVarFlag:
sed -e 's|\(d\.getVarFlag \?\)( \?\([^,()]*, \?[^,()]*\), \?True)|\1(\2)|g' \
-i $(git grep -E 'getVarFlag ?\( ?([^,()]*), ?([^,()]*), ?True\)' \
| cut -d':' -f1 \
| sort -u)
(From OE-Core rev: 26c74fd10614582e177437608908eb43688ab510)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool modify/upgrade are not currently equipped to handle conditional local files
in SRC_URI, and provide only the main no-override set in a workspace under
source/component/oe-local-files/ (this is done via meta/classes/devtool-source.bbclass).
On the other hand, updating the changes from workspace into a recipe
is run iteratively against all overrides; this works for patches (as they
all are directed into their own override branches in the workspace
git source tree), but breaks down when trying to match local files
in a workspace against local files in overridden SRC_URI lists, resulting in
bad recipe breakage.
(there's an additional twist here: existing code has a guard against this
but the guard relies on metadata in workspace .bbappend that is only there
in modify operations, but not upgrades. This commit replaces the guard
with a general check that will work everywhere).
Implementing multiple sets of local files is significant work; let's for now
simply not touch local files in recipes except when on the no-override variant.
Also, adjust the selftest cases to include conditional local files in sample
recipes, so the situation is covered by the tests.
(From OE-Core rev: 3a8654b860fa98f94e80c3c3fff359ffed14bbe7)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'devtool modify' writes additional settings to workspace .bbappend so that this
can be handled correctly, but 'devtool upgrade' does not. This adds the missing
settings.
In particular, local files should not anymore mysteriously disappear from
SRC_URIs on upgrades.
(From OE-Core rev: 0817aa5537a8d7cc9591c53dfaa1d225f4c327f7)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are typically auto-extracted with modify/upgrade from recipes
and can be easily recreated. On the rare occasions where they need
to be reused, they are still available under workspace/attic (which
is already used for old recipes and appends), so nothing gets lost.
This avoids the annoyance of devtool refusing to proceed because
there is a previous source tree in workspace/sources.
For independent source trees behave as before: do nothing.
Adjust the test that previously deleted those trees by hand.
(From OE-Core rev: 9bfb95d070d68d5ab5adfe0ea096f5fbf9cad8b0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where there isn't a copyright statement, add one to make it explicit.
Also drop editor config lines where they were present and add license
identifiers as MIT if there isn't one.
(From OE-Core rev: deb3ccec53e0bd63bc4235cf2b0d3fc781687361)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a coding error in the second invocation of _upgrade_error:
rf is passed into it before it is initialized in the try: block. And so
bogus recipes are left behind in the workspace, causing breakage.
Instead, rewrite the functions to take the recipe directory name in the
workspace layer, which can be calculated in advance.
(From OE-Core rev: e653996369c1d2b5ac8367ad85f4816d679b6c98)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If devtool finish needs to create a patch and have it applied to the
sources for a recipe where S points to a subdirectory of the sources,
then the patch needs to be applied at the root of the repo i.e. we need
to add a patchdir= parameter to the SRC_URI entry.
(From OE-Core rev: ad3736d9ca14cac14a7da22c1cfdeda219665e6f)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If (perhaps foolishly) at your configuration level you have e.g.
SRC_URI_append_pn-recipename = " file://patchname.patch"
and then run devtool modify on a different recipe, an error occurs:
INFO: SRC_URI contains some conditional appends/prepends - will create branches to represent these
...
ERROR: [Errno 2] No such file or directory: '/path/to/downloads/patchname.patch'
pn- overrides would not constitute an alternative configuration that we
should handle in this context, so just ignore them to avoid the issue.
(From OE-Core rev: 3f2a812ade42ece0bb59b2d303125a91b29936dd)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In particular this resolves devtool's inability to pick a branch
when the same tagged commit is avaiable in main and in a release maintenance
branch.
Thanks to Peter Kjellerstedt for the suggestion.
(From OE-Core rev: bcb21ee2760a2c76039412a56c6cda43fbf96fd0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
deploy-target may fail the second time with "pseudo abort" because
devtool-deploy-target-stripped is deleted outside of pseudo's fakeroot
context.
(From OE-Core rev: 2338a33b690b0bbe279cde3f73764911b239cb50)
Signed-off-by: Florian Amstutz <florian.amstutz@scs.ch>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit 044fb04d in bitbake (fetch2: Allow whitespace only mirror
entries) there is no need to separate the entries in SSTATE_MIRRORS
with "\n".
(From OE-Core rev: 6e66ec3cd201d32d3d97df2222f41bb8c475fb69)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class was added by me back in 2007 and has changed one for a whitespace issue
since. It only has two lines and neither are particularly useful, one was replaced
by the nopackages class, the other adding recursive dependencies also is now
mainly problematic adding tons of unneeded dependencies. The name is hard to
understand and the class doesn't have a clear purpose. Drop it.
Remove the references in devtool (which may be the one reason to keep it around
but in my view still not worth it).
(From OE-Core rev: 6e2cbfc561dac89bf9183d24d90e52f7d9117826)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a long standing bug where FILES_INFO isn't written into pkgdata
with a package suffix. This means if the files are read into the datastore
as intended, the last one "wins".
Fix this to work as intended. Most of the call sites using the data need
to be updated to handle this and the overrides change correctly.
Also fix some other problematic references noticed along the way.
(From OE-Core rev: a1190903e0a61a12c9854c96af918ae8d12c6327)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The automated conversion of OE-Core to use the new override sytax isn't
perfect. This patches some mis-converted lines and some lines which were missed
by the automation.
(From OE-Core rev: 4e9a06b64b43131b731fb59a0305f78a98e27fbd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When S is set to a sub-directory of upstream source, the license
checks and the bbappend writing (specifically, setting EXTERNALSRC)
need to operate on that sub-directory.
'devtool modify' already has similar logic, and it was copied from there
and adjusted.
(From OE-Core rev: fd77e356d4507405fde352c8bba7d3842518bbdd)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit a2db4fa127 added ${WORKDIR}/deploy-* to
PSEUDO_IGNORE_PATHS. This breaks the --strip mode since ${D} is copied to
deploy-target-stripped. Use the directory devtool-deploy-target-stripped
instead.
[YOCTO #14451]
(From OE-Core rev: 02661f20faf11d0fa2f1874bd423f5d9fa7a31c9)
Signed-off-by: Florian Amstutz <florian.amstutz@scs.ch>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's a number of recipes (such as nettle or glib) which were upgraded
incorrectly due to rebasing only the default set of patches in main SRC_URI.
Native-only or musl-only patches were not handled, causing do_patch fails
and overall misery.
Unfortunately, this also necessitates aborting any incomplete rebases as
devtool needs to be able to return to the original branch to complete
the upgrade command.
Also, do not add devtool-patched-%version tags, as they are not used anywhere,
and it's unclear how to extend them to cover multiple override branches.
(From OE-Core rev: 00131cbc969f6a73caffe068fcb983287cbe577f)
(From OE-Core rev: 588d04748dd89b5371ca9144666e97ec82dd6204)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Incremental build in Docker fails with:
OSError: [Errno 18] Invalid cross-device link
when source and destination are on different overlay filesystems.
Rather than adding fallback code to every call site, use a new wrapper
in bitbake which detects this case and falls back to shutil.move
which is slower but will handtle the overlay docker filesystems correctly.
[YOCTO #14301]
(From OE-Core rev: 656a65b2b84e7d529b89cf5de7eb838f902d84a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_kernel_configme task is no longer part of SRCTREECOVEREDTASKS,
its been removed from the kernel-yocto.bbclass since b72dbb2e4, but
there wasnt a matching patch for devtool for those changes.
This patch enables us to invoke the do_kernel_configme task when
using a devtool workspace, it also prepends a check for an existing
.config file in the source directory and moves it if thats the case,
since when using devtool modify a .config is created and
do_kernel_configme complains about it, this is not the case when
using bitbake since the .config file would be on B instead.
Alowing do_kernel_configme to run also fixes the flow where testing a
new config fragment from devtool workspace isnt added properly
(config queue shows it as ///frg.cfg) and as a side effect it never
gets merged into the final config.
(From OE-Core rev: 08dcc0e68095dcf2a159546a48b29d40c9aabc0b)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alhe@linux.microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add relative path if file is under directory.
[YOCTO #13738]
(From OE-Core rev: 19ddacc1b38f9ebb86a9359963ccc3c707f7125e)
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If do_patch task is disabled then prepare do_configure dependencies to
fetch external sources and create symlink to ${S} in devtool workspace.
[YOCTO #13036]
(From OE-Core rev: 9e47319bfe62d289b90f7545a64dbdc1cbde7f1d)
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If nothing else is specified, 'git init' uses its default repository
template from the install location (e.g. /usr/share/git-core/templates),
which already includes an info/ subdirectory. However, when setting
init.templateDir to a different template path in ~/.gitconfig, this
isn't necessarily the case, and it can lead to setup_git_repo() failing
with stack traces like:
File: '.../scripts/lib/devtool/__init__.py', lineno: 234, function: setup_git_repo
0230: pass
0231: if 'singletask.lock\n' not in excludes:
0232: excludes.append('singletask.lock\n')
0233: bb.warn("try writing excludefile")
*** 0234: with open(excludefile, 'w') as f:
0235: for line in excludes:
0236: f.write(line)
0237:
0238: bb.process.run('git checkout -b %s' % devbranch, cwd=repodir)
Exception: FileNotFoundError: [Errno 2] No such file or directory: '.../devtooltmp-6m36b181/workdir/foobar-1.0.1/.git/info/exclude'
Fix this edge case by creating the .git/info/ directory first.
Fixes: 334ba846c795fc0d8c73 (2018-02-01, "devtool: set up git repos so that singletask.lock is ignored")
(From OE-Core rev: 148a23e4d5ceaf655ccacb52deca4ba501f12975)
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
