Update importing a build directory to support where bblayers.conf
sets BBLAYERS to a value that includes a variable reference e.g.:
BBLAYERS = "${TOPDIR}/../meta \
${TOPDIR}/../meta-selftest"
[YOCTO #13707]
(Bitbake rev: 5bd29d448a31c132afd6fc0127029e246759b87b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we fail to run the command to generate the tap devices then we should
show a reasonable message and then exit, without showing a traceback.
"return 1" at this point in the code does nothing because the caller
doesn't check the return, so just use sys.exit().
(From OE-Core rev: 47e40fdd7dd58bde4e017e2375c16450fcb14eca)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is not a good idea to mix logging and calls to print() - if the
output is being captured the result can be that the two types of output
are not recorded contiguously; this could be observed if an error
occurred running runqemu from inside testimage:
---------- snip ----------
ERROR: core-image-minimal-1.0-r0 do_testimage: Output from runqemu:
runqemu - INFO - Continuing with the following parameters:
runqemu - INFO - Setting up tap interface under sudo
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
runqemu - ERROR - Setting up tap device failed:
Command '('sudo', '/home/paul/poky/poky/scripts/runqemu-ifup', '1000', '1000', '/home/paul/poky/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin')' returned non-zero exit status 1.
Run runqemu-gen-tapdevs to manually create one.
runqemu - INFO - Cleaning up
KERNEL: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/bzImage--5.2.20+git0+bd0762cd13_dd25a04fc5-r0-qemux86-64-20191205213021.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4]
CONFFILE: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.qemuboot.conf]
---------- snip ----------
What we should see here is the KERNEL, MACHINE, etc. lines appearing
immediately after the "Continuing with the following parameters:" line
as they do when you run runqemu directly. If we put all of the lines
through the logger instead then it works properly.
(From OE-Core rev: ca64a3d490fbe1bf87c9f1dd6d87a1ecdeba8325)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we get here in the code it's because runqemu has failed, this is not
a debug situation - we need to see the output, so print it as an error.
Fixes [YOCTO #13681].
(From OE-Core rev: c1def38c680d64c992839166bbf9bec51eb0788a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If runqemu fails, there is some logic to run a set of commands to dump
various bits of information that might help debug the issue
(particularly in a busy situation such as on the autobuilder). One of
those commands is "top -bn1", however top restricts the output to the
width of the calling terminal, and for whatever reason this is a little
restrictive when called from inside testimage, so set COLUMNS in the
environment to a high value to fix it. (Another way is to use the -w
option, but that is not supported by our default busybox configuration
so it will then fail when this same list of commands is used on the
target).
(From OE-Core rev: 07da998f5aa6c3f5ffeee5150fc579e8a1051ba4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If runqemu fails, there is some logic to run a set of commands to dump
various bits of information that might help debug the issue
(particularly in a busy situation such as on the autobuilder). However,
when we try to run these we are inside the normal build environment
which restricts commands to be run on the host to those specified in
HOSTTOOLS. Since this isn't a place where host contamination is going to
be a problem, override PATH to a reasonable default so that we run the
actual host tools directly to avoid the issue. (Logically we would want
to use the original PATH value here, but it is not easily accessible.)
(From OE-Core rev: 3f6dcf67bccb4f0fc1a9a64e02bd0e2da620ad0e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the reproducible_build class is inherited then there may be a
"source-date-epoch" subdirectory in a fetched source tree; devtool
upgrade was not expecting that in the upgraded source. Take a small
snippet of code from recipetool create which already handles this,
and make it a shared function that can be used in both places.
Additionally, fix an assumption that the source is always in a
subdirectory in the cleanup code that blocked debugging this.
[YOCTO #13635]
(From OE-Core rev: 0d642861cd9cf034b8d4951433980addc215d4fd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a single-commit series had a shortlog containing a "/" character then
that prevented putting the shortlog into the subject of the cover letter
message. Use a different separating character with the sed command (one
much less likely to appear) in order to fix it.
(From OE-Core rev: d4c3f93d7407ac1ea20b33149f20153972d631c0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When attempting to create a pull request, we look at the remote URL in
order to extract information to include in the cover letter. However,
the assumption was that the remote is an SSH URL i.e. containing '@'
which is not always the case (the pull and push URLs might be different,
or we might be pushing via https) - if it wasn't the script just gave up
leaving you to manually edit the URLs in the email. With a few minor
tweaks to the regexes the script will work for these cases as well.
(From OE-Core rev: 675e88e6e0bbd5ab2dcd4bdf97b0de59925a1be6)
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>
If a setup.py file exists it ought to have something in it before we
consider the source tree to be a Python module and treating it as such.
(A counter-example is https://www.bro.org/downloads/binpac-0.50.tar.gz -
it's not clear why this has a zero-length setup.py in it but we should
pay no attention to it.)
Fixes [YOCTO #12923].
(From OE-Core rev: 548a5c8f42c6ac1b0f7962926d05276e71505678)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
P (which is ${PN}-${PV}) isn't terribly useful in this context - we
don't really care what the version is, but we do want to know what the
recipe is so we can find it or set PACKAGECONFIG_pn-<PN> in our
configuration, so display ${PN} instead.
(From OE-Core rev: 7facaacd145c2924414ad63ddce07602a72d02c1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The blacklist, whilst previously useful for safety, is now becoming
obsolete - on my current system, the main storage is at /dev/nvme* and
if I plug in a USB stick it shows up as /dev/sdb which was previously
blacklisted. To make this more flexible, remove the blacklist and
instead check if the specified device is mounted, has a partition
that is mounted, or is otherwise in use according to the kernel, and
show an appropriate error and quit if so.
To make this robust, also ensure we handle where the specified device is
a symlink to another device.
(From OE-Core rev: 49043de1a7716ad612fb92a2e8a52e43d253c800)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I'm not sure what's going on but having this symlink present is causing
git problems rebasing just by being present; deleting it and checking it
out again does not fix it. In any event this is not the standard way of
sharing files between recipes in the same directory - extending
FILESEXTRAPATHS is, so use that method instead.
(From OE-Core rev: 9ddf0597b4ea40b4c2be2eb0f01f833b5ec23030)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use tinfoil to enumerate recipes and get the value of RECIPE_MAINTAINER
to make it a bit more reliable in the face of do_checkpkg issues we are
currently seeing on the Yocto Project autobuilder. This also makes it a
little less painful to re-execute test_maintainers() since you don't
have to wait for bitbake -c checkpkg to complete every time.
Note that the new test has been written in such a way that it will still
function if RECIPE_MAINTAINER values are ever moved to the recipes.
Also, the test still currently fails as there are recipes that don't
have an assigned maintainer.
(From OE-Core rev: 47282a2f6f12acebf58961ea9410cfbc335d560b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some tests for functions in meta/lib/oe/recipeutils.py, in
particular for a few issues I've just fixed. I haven't added tests for
all of the functions - some of them are already being tested via devtool
in any case.
(From OE-Core rev: 72d0cb3f8f1e69aeef93ea0bc90db3e8b8d6f94c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These date from the time before Tinfoil's API covered this functionality
(back when you could actually access cooker from a tinfoil-based
script).
(From OE-Core rev: fc8098756e8d1d995e3c68e4addc1a5e3596d2ae)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code here wasn't correctly getting the variable history for
varflags, so for example if you did a devtool upgrade on a recipe where
the SRC_URI checksums were in the .inc file (typical for python recipes
in order to support both python 2 and 3) then after the upgrade the
new values would be set in the recipe and the old values were left in
the .inc, which is not right. Teach the code here how to get the history
for varflags so it works properly.
(From OE-Core rev: f077ab3ad67b2f3eb4aa8882fe2e7aef2d09a26c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we were setting a variable and part of the variable's value was being
set in a class or a .inc file, we were still just setting the value
outright on the assumption that it was too hard to do otherwise. With
some careful use of the variable history we can do better for certain
situations i.e. when the recipe does not currently set the value
outright.
Additionally, correctly remove _appends for variables we are changing if
we're trying to remove the value added in the _append.
Fixes [YOCTO #12623] and partially fixes [YOCTO #9360].
(From OE-Core rev: f798d963db77db66a2a5a4b8d4c157d46ede417f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to both the README and source headers, the LICENSE value for
socat is explicitly GPLv2, not v2 or later, so adjust LICENSE
accordingly (leaving aside whether "GPL-2.0+-with-OpenSSL-exception"
should actually be considered a valid LICENSE string or not).
(From OE-Core rev: 466044a341a8b42159bd9388950c9079e0d7a2c3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The comment here stated that openssl is dual-licensed, but that would
mean that either of the two licenses could be used which is *not* the
case [1]. However LICENSE = "openssl" *is* correct because in OE that
maps to a generic license file which includes both licenses, which
makes sense because there isn't really any such thing as OpenSSL that
would be covered by the "OpenSSL license" and not the "SSLeay license".
Correct the comment to avoid any confusion.
[1] https://www.openssl.org/source/license.html
(From OE-Core rev: 6c821ce6ecae789320b31ec55c83907d6dd78359)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In finalize() we save event handlers, register the ones relevant to the
recipe being finalised, trigger events, and then restore the handlers so
that one recipe's custom handlers (actually implemented within a class
inherited by the recipe) do not affect other recipes. However, if an
exception occurs during parsing, the saved handlers were not being
restored. Use a try...finally block to ensure that the handlers are
always restored.
This issue became apparent since in OpenEmbedded-Core we have recently
introduced a find_intercepts() handler for the
bb.event.RecipePreFinalise event in image-postinst-intercepts.bbclass
that images and old-style SDK recipes will end up inheriting. So far it
doesn't seem that the the error has manifested itself in normal builds,
but when parsing OE-Core recipes in the OE layer index it has:
core-image-rt-* image recipes were parsed which in the default
configuration raise SkipRecipe. The next non-image recipe that is parsed
will trigger a real exception, because the find_intercepts() handler is
still registered and gets fired, but in the context of the new recipe
the POSTINST_INTERCEPTS_PATHS variable is not set, and the code in
find_intercepts() is written with the reasonable assumption that that
isn't possible given that the class itself sets a default, and thus it
fails.
(Bitbake rev: e5f1f8fa201774e0c3c554d59b277baa2128708f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of the devtool tests make changes to files under meta/ -
legitimately since we want these tests to be working with real recipes
and associated files. Unfortunately with the new oe-selftest
parallelisation this can break other tests if files go missing at the
wrong time (among other scenarios). To avoid this issue, simply take a
copy of the core repository and use that for these tests. (We copy the
entire repository since changing the path of meta/ influences COREBASE
and thus we need to have things like scripts/ alongside as well).
(From OE-Core rev: 2457cd57b4195924ef127f497efa2f34f411e660)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a callback that lets you modify or remove items in addition to the
current scheme where you can only add or remove. This enables you to for
example replace a layer with a temporary copy (which is what we will use
this for first in OE's oe-selftest).
(Bitbake rev: bfedb4e85a84e817dbe5d8694b8f8fcdd6f2f22a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable is PACKAGE_WRITE_DEPS as seen in the default below the
comment.
(From OE-Core rev: 364449251ffe4ff2c11acaa258edcec244c38818)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we're not reporting the related fields (as of openembedded-core
8658b3677b9f7cb70806061c41570c709086ef05) we shouldn't expect to see
PR reported here since it's not monitored by buildhistory-diff. However,
with a bit of messing about we can check for the exact output that we
should now see as a result of the test changing PR to go backwards.
(From OE-Core rev: f9c233908e6ada208d7abfdfe3ff98c6b278f405)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pseudo won't always be in the native sysroot for a recipe, so we
shouldn't be complaining if it isn't there.
(From OE-Core rev: 11efc94742088ec6fbf2a86000e98286b0b529ef)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you pass quoted arguments to oe-run-native, they need to be passed
as-is to the underlying tool. Putting quotes around $@ ensures each
argument is quoted individually.
(From OE-Core rev: a8758653500a2458cd91bf1aa5eb666ad2b45df4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All values written out to pkgdata are escaped (see write_if_exists() in
package.bbclass). In practice there tend not to be characters that need
escaping except in the scriptlets (pkg_preinst, pkg_postinst, pkg_prerm
and pkg_postrm) where currently we still see the escape codes in the
corresponding files within buildhistory (e.g. \n and \t) and thus also
in the output of buildhistory-diff, hindering proper diffing of changes.
To fix this, when we read values from pkgdata and write them out to
buildhistory, we need to interpret the escape codes by doing the exact
reverse of what we do in package.bbclass.
(From OE-Core rev: c258379181a438cb01728d223b3d05e0ab205941)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The FILELIST field of the package info file in the buildhistory
repository is a space-separated list of all of the files in the package.
If a name of a file packaged by a recipe contains a space character then
of course the result was that we didn't handle its name properly. To fix
that, use quotes around any filename containing spaces and at the other
end use these quotes to extract the proper entries.
Fixes [YOCTO #12742].
(From OE-Core rev: 801b705957dc683030d11393f43407d0b3506b6a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original idea here was that changes to certain fields might be able
to be explained if there was a change to another field, for example if
RDEPENDS changed it might be because DEPENDS changed. Thus we were
printing this kind of thing out with each change. Unfortunately in
practice this turned out to be noisy and not particularly useful, so we
might as well remove it.
Fixes [YOCTO #7336].
(From OE-Core rev: 8658b3677b9f7cb70806061c41570c709086ef05)
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's possible that a trailing or extra slash somewhere in the external
source path could result in the directory not being removed from
cleandirs; it's also possible that a cleandirs entry is somewhere
underneath the source tree and that tree should never have parts of it
deleted by the build system. Use oe.path.is_path_parent() (which makes
paths absolute before checking them) to find out if any path in
cleandirs is anywhere underneath the external source path, and drop it
if it is.
(From OE-Core rev: 87ec0fb470274d980f8553a85f778809c269c5d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the existing oe.recipeutils.split_var_value() function to split the
unexpanded value of the cleandirs varflag, in case it contains python
expressions - we don't want to split the expression itself as the chunks
will not expand properly individually and we can miss something that
expands to the source tree (and thus it can get deleted, the avoidance
of which is the whole point of this code).
(From OE-Core rev: 611cee69d7300a4746edd752c9557af60e7beecc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was removed in the bitbake repository back in 2010 (bitbake
revision 24857e2ceb405916b0b0b3e75c6c2375a909b9ba) - it's not clear
to me what happened, but for some reason the file remained in the poky
repository. However it does not appear that it has been used since then
and the reasons for removing even more valid now than they were then -
the code has moved on even further, we have memory resident bitbake
server, and if we were to re-implement this we would do it in a
different way. Drop the file and bring us back in sync with the bitbake
repo.
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>
* 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>
Prompted by bitbake commit 2ba8a6b25ccc12e7b543e8450121e5311c7a701d,
add .txz to the list of archives used within get_recipe_local_files()
here as well.
(From OE-Core rev: 28466586f4777f11f0a29ed5ebe9734a4e15920e)
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>
In a few places we have checks to see path B is the parent of path A, by
adding / to the end of the path B and then seeing if path A starts with
the suffixed path B. Unfortunately there are two potential flaws:
(1) path A needs to be suffixed with / as well or the directory itself
won't match (semantics perhaps, but in a lot of scenarios returning True
is correct); (2) you need to run os.path.abspath() on both paths first
or you will wrongly return False for some relative paths where you
should return True. Let's solve this once and for all by writing a
function that takes care of these and put it in oe.path.
(From OE-Core rev: dd3d4b0367272a5826a9a51afa26f426dd003e5d)
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>
This module refers to oe.types, so it needs to actually import oe.types.
Fixes errors when parsing certain OE-Core recipes within the layer
index update script.
(From OE-Core rev: 26ff9d2835a24a84c7f2bf9c829a13ed568c9ea0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mkelfimage is about to be removed, so test_devtool_modify_git needs to
use a different recipe. psplash is a reasonable choice given it uses a
git repository (and probably will forever), and doesn't have too many
dependencies, so change the test to use that recipe instead.
(From OE-Core rev: daf583efc87faa058684dfe34df596d088caa8ef)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a patch which has been submitted upstream to support producing
bindings for Node.js 7+. This is important to enable mraa to build with
newer Node.js versions.
Fixes [YOCTO #12293].
(From OE-Core rev: 1825473ba35b4557db99786420ca451068922223)
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>
acinclude.m4 is about to be removed from the lzo recipe which breaks
test_devtool_update_recipe_local_files_2. Create a synthetic recipe in
meta-selftest with some local files and use that instead.
(From OE-Core rev: ed27470fa6a9f3cc1a0eb884474fe7985babde7a)
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 bug is present or the user has set PATCHTOOL = "git" on a source
tree that isn't git, if we try to perform git operations (such as
committing or changing branches) when extracting source, then we might
in fact be running those operations on the metadata repository if the
build directory is underneath, say, poky or OE-Core, and that could
make a mess. Check if the source tree is a git repository and refuse
to continue if it isn't.
(From OE-Core rev: 59ae5b7cbfeedb216a57c3f77fe52527b6c918cc)
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>
* NATIVE_INSTALL_WORKS hasn't been used in a very long time, so there's no
need to be setting it here.
* RCONFLIGHTS was clearly a typo.
(From OE-Core rev: b0146f21765b10c1f71807372f69a286bc9c2474)
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 matching recipe is not found then return Null instead of raising
KeyError because we were blindly using None as a key for pkg_fn.
(Bitbake rev: 431e89e322850a2497157c3c0843da9df6bc9a3e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -i option supports more than one class, but the help didn't mention
that.
(Bitbake rev: 1060955c4aa2ef66cdb4f0549f9bd8c1c332673c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you can add multiple layers at once, it stands to reason that you
should also be able to remove more than one at a time.
(Bitbake rev: 2f2033836a5ce4064d9e4f263788a563001bc008)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow specifying multiple layers with bitbake-layers add-layer so that
you can add more than one in a single command. This is not just useful,
it's actually pretty important if you need to add a layer and its
dependencies at the same time - since we now go through a parse process
when the layer is added, without this you have to add them all in just
the right order and wait for the parse each time which is somewhat
painful.
(Bitbake rev: ad6b14f01aa326a1c6baa31bfac33be238bce805)
Signed-off-by: Paul Eggleton <paul.eggleton@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>
I noticed that using bitbake-layers add-layer followed by a devtool
command resulted in bitbake re-parsing all of the recipes, which is
annoying. Upon closer inspection I could see that devtool was moving the
workspace layer path to the end of BBLAYERS if it happened to be
somewhere in the middle - there's no need for it to be doing this. This
occurred because we were passing the current workspace path to remove
and the "new" path to add even if the path is not being changed, and I
think earlier versions of bb.utils.edit_bblayers_conf() didn't move the
existing entry under these circumstances as it clearly does now. Fix it
so we only pass the path to be removed if we're actually changing the
path.
(From OE-Core rev: 284426dbad91a3c52eaf7da5c58fe8a2c2dfb826)
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 a value was split over multiple lines (e.g. as SRC_URI usually is)
then we were inserting the value as one item in the lines list with
newlines between each line. There's nothing wrong with this if you're
writing the list out to a file, but if you want to generate a patch (as
patch_recipe_file() will do if the patch parameter is set to True) then
the diff output looks a bit odd. Split the value before adding it to the
lines list to resolve this.
(From OE-Core rev: 44f4c97234623cbd770fbc86eabb04e7e0c91061)
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>
find_layerdir() should really return absolute paths, so make it do so.
This fixes devtool finish not deleting files it should do after devtool
upgrade if the specified path is relative, since the devtool finish code
was assuming that find_layerdir() was returning an absolute path.
Fixes [YOCTO #12318].
(From OE-Core rev: 5e3fe00a0233d563781849a44f53885b4e924a9c)
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 source tree happens to contain a kernel module as an example, a
test or under a "contrib" directory then we shouldn't be picking it up
and making the determination that the entire thing is a kernel module.
An example that triggered this is zstd, which ships a kernel module
under contrib/linux-kernel:
https://github.com/facebook/zstd
(From OE-Core rev: c2b3154158d4bb0855daa56477393341139d4cf9)
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>
We shouldn't be passing a relative path to the plugins if that's what's
been specified on the recipetool command line.
(From OE-Core rev: 949067384c5166058ebc76f931cc492dad1db645)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With a '*' as a wildcard for the signature here we can also match a
portion of the task name with the result that we may match a sigdata
file for the wrong task. Luckily the signature is always the same
length - 32 characters - so we can simply use 32 '?' characters instead.
(A regex would have been another alternative, but the wildcard should be
effective and I felt like a regex would complicate the code more than
this solution).
Fixes [YOCTO #11763].
(From OE-Core rev: 73c6f85457361cd82d44838946aa81ba9bd1662a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The most common usage for buildhistory is with commits enabled so that
you actually collect history, rather than just keeping a snapshot of the
most recent build state, therefore default BUILDHISTORY_COMMIT to "1".
This really ought to have been the default in the beginning, I can't
really explain why it wasn't.
(From OE-Core rev: 8018a2349b7ad5ab27731c93a49603adf5f72fc2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Python 3.6, glob.glob() was reimplemented to use os.scandir() (which
itself appeared in Python 3.5), thus our monkey patching of os.listdir()
here was no longer effective. The end result was not only that bitbake
wouldn't notice added recipes or bbappends with BB_SERVER_TIMEOUT set
when being run with Python 3.6 (the shipped Python version on Fedora 26
and some other distribution versions), it also broke devtool modify,
devtool upgrade and devtool extract since they rely on the ability to
create a bbappend on the fly and have bitbake pick it up.
To fix it, do the same monkey patching for os.scandir(), which needs to
be conditional upon that actually existing since we have to support
Python 3.4 that doesn't have it. Long term we should probably look for a
better way to handle this that doesn't involve monkey patching Python
library code.
Fixes [YOCTO #12185].
(Bitbake rev: d02e90db32e7ee341c2ba3be79b0627d8796bdd6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't need a dependency on this variable changing, and having one
causes locked signature warnings during eSDK installation if you have
INITRAMFS_IMAGE_* set (since TOPDIR will always be different between
the eSDK and the environment in which it was built).
Relates to [YOCTO #12102].
(From OE-Core rev: 073610af04be326f9245ca91714526b390fb72cd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"Yocto Project Compatible" [1] is a programme which requires you meet
specific criteria including going through an application process - it is
not sufficient simply to run the script we have created here and have it
produce no warnings/errors. To avoid people being confused by the fact
that this script uses the term "compatible" or variations thereof,
substitute usage of that word with "check" instead. The functionality of
the script is unchanged.
[1] https://www.yoctoproject.org/ecosystem/yocto-project-branding-program
(From OE-Core rev: 2a6126a115f10750ea89f95629d3699ad41c5665)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To help users find the work and log directories (especially within the
eSDK) we create symlinks to these from the source tree. However during
do_buildclean we call "make clean", and some project Makefiles which
delete something like "*/*/lib" which will match files underneath the
oe-workdir symlink and fail. do_buildclean is called from do_clean which
is in turn called by devtool reset by default, and thus devtool reset is
blocked. An example of a recipe where this is visible is the openssl-qat
recipe in meta-intel.
In order to fix this, delete the symlinks at the start of do_buildclean
since we shouldn't need them at that point anyway, and thus make clean
won't be able to trip over them.
Fixes [YOCTO #11036].
(From OE-Core rev: 927b3b05a7f6b85967f7375b1942605fe8d37d0c)
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>
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>
In collect_bbfiles() we're monkey-patching os.listdir in order to find
which directories to watch, and then undoing that when we're finished -
however if an exception occurred for any reason there was nothing to
ensure the latter occurred. This may not have caused any issues, but as
this kind of thing really ought to be secured using try...finally just
in case, so do that.
(Bitbake rev: 013047484a03185c0ce281c53c1db4949cdc4e69)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code that was supposed to watch directories along BBFILES for
creation of new files wasn't working in the case where the directory did
not initially contain any matching files - since in updateCache() we are
passing the directory path to add_filewatch() and the latter function
calls os.path.dirname() on the path on the assumption that it is a file
path, and thus the parent of the directory got watched but not the
directory itself. (If the directory wasn't empty everything worked fine
since add_filewatch() was called elsewhere with the path to one of the
files in that directory, and thus the directory got watched). Add a
parameter to add_filewatch() to tell it we are passing it directory
path(s) rather than file path(s).
(Bitbake rev: 47a34dee08fcc25d896a1bdf16fa86267f0b898f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in scriptutils which implements the logic for running the
editor used by devtool edit-recipe looks at the VISUAL environment
variable before EDITOR, and thus if VISUAL is set in the environment it
will override the EDITOR value we are setting here, the editor (usually
vim) launches and there's nothing to stop it running forever short of
manually killing it. Set VISUAL instead to fix this.
Apparently VISUAL is in fact the variable we should really be preferring
here - I don't think I knew that but somehow I got it right in the code,
just not in the test. Here are the details for the curious:
https://unix.stackexchange.com/questions/4859/visual-vs-editor-whats-the-difference
Fixes [YOCTO #12074].
(From OE-Core rev: 6a7c50def569b5e86aa17bd9b287e8c63781dcb0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printing the last 10 lines of bitbake-cookerdaemon.log when the server
fails to start can sometimes result in printing the output from a
previous run, which could lead the user completely down the wrong path
in terms of the cause of the failure. Use a known start text containing
the time which we can then look for when scanning through the log, and
then grab the last 10 lines of that part instead.
Fixes [YOCTO #11903].
(Bitbake rev: 567f2cf1bc455b4f3cfb1cbd7f25145360b05a62)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The whitelist shouldn't have to be populated in order for the
enforcement to work properly - check if the list is not None in order to
determine whether the functionality is enabled or not since that is how
the function that sets up the list behaves.
(Bitbake rev: 7b1e79c352ca6eef1693d8abfacf7505544f1caa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.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>
When the UI disconnects, we can throw away any server-side remote
datastores we created in response to calls from the UI, and we *must*
drop everything in extraconfigdata or it will taint any future
operations.
Dropping extraconfigdata upon disconnect fixes taskhash mismatch errors
when running devtool.DevtoolTests.test_devtool_update_recipe_local_files
within oe-selftest with BB_SERVER_TIMEOUT=100 in OpenEmbedded.
(Bitbake rev: 1ca2eec459424892391f060442ef38cf28d6a54a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're implementing reset() in SignatureGenerator at all (and we need
to for a basic non-OE BitBake setup where that is the default signature
generator), then we need it to be clearing out the internal values
properly.
(Bitbake rev: 13f52d38fdbcb84c2a0c46f85baa44b22d53fdc1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When fetching source for the first time within scripts such as
OpenEmbedded's recipetool, we don't want to be showing warnings about
NPM_SHRINKWRAP or NPM_LOCKDOWN not being set since there's no way we
could have set them in advance. Previously we were using
ud.ignore_checksums to suppress these but since we are now using a more
standard task-based path to fetch the source, we need to disable these
through the metadata. Look for a "noverify" parameter set on the npm URL
and skip the checks if it is set to "1".
(Bitbake rev: 8c4b35d1e4d31bae9fddd129d5ba230acb72c3bb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you run some other operations that result in the cache being
populated, and then call buildFileInternal(), then you can end up in a
situation where the cache already contains information about the recipe.
For example in OE this can now happen when you use devtool upgrade.
Normally this doesn't cause any problems, unless you have a non-absolute
path in BBLAYERS - in buildFileInternal() we are calling matchfile() which
will convert the filename to absolute, but later when taskdata goes to find
the providers of the recipe it finds the non-absolute path, sets up the
task information using this and then the runqueue can't find any tasks
matching the absolute path. To fix this, back out the optimisation I did
earlier in bitbake rev ba53e067a2d448dd63b4ca252557ce98aa8e6321 to avoid
calling parseConfiguration() again, which is unfortunate but does result
in the cached information being that causes the problem being cleared
out.
This fixes "Task do_unpack does not exist for target ..." running
devtool upgrade within intel-iot-refkit.
(Bitbake rev: f120355eaec4571ba6d60fc5f7ae9e1f31d846d1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton