| Age | Commit message (Collapse) | Author |
|---|
|
The Makefile does not define a "clean" target, so set CLEANBROKEN to
ensure we don't try to run "make clean".
(This was found when using bitbake -c clean with the externalsrc class
enabled for the recipe, which runs "make clean" if B==S and CLEANBROKEN
is not set.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The Makefile does not define a "clean" target, so set CLEANBROKEN to
ensure we don't try to run "make clean".
(This was found when using bitbake -c clean with the externalsrc class
enabled for the recipe, which runs "make clean" if B==S and CLEANBROKEN
is not set.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The Makefile does not define a "clean" target, so set CLEANBROKEN to
ensure we don't try to run "make clean".
(This was found when using bitbake -c clean with the externalsrc class
enabled for the recipe, which runs "make clean" if B==S and CLEANBROKEN
is not set.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
There were two places in the file checksum code where we split the list
of files into items and then split the items into <filename>:<exists>
pairs. We did discover that we weren't handling spaces in filenames back
in bitbake rev 87282b283921a58426f24fb21151db457c5bca66 but we only
fixed one place. Split out the corrected code into a function and make
both places call it. Additionally, the new function was tweaked so that
it splits on the last : rather than the first, and only splits once, so
that any colons in filenames won't be split on. (If a filename happened
to have :False or :True in it we'll still have an issue, but I think
that's rather unlikely.)
This bug was triggered in OE if you used "devtool modify cmake" followed
by "bitbake cmake".
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The gcc recipes use a shared work directory populated by a separate
gcc-source recipe, and thus they disable do_unpack and do_patch. That
caused devtool's source extraction to fail immediately because it
relies on those being there. Add some code to redirect to the
gcc-source recipe for gcc in order to make things work and allow devtool
modify/upgrade/extract to work with gcc and related recipes.
(I considered taking a copy of the work-shared directory but then
immediately ruled it out, since that would mean we would not have a
proper git tree with the patches we are applying as commits.)
Fixes [YOCTO #13036].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
devtool modify/upgrade/extract create branches for any overrides that
would modify SRC_URI to enable updating any conditional patches when the
recipe is updated, but if applying one of the conditional patches fails
then the entire operation fails. Fix the broken patch on sysklogd to
avoid that here (it's probably been broken since
25018c4807a431382488dcf46731c83c2e9baffb back in July 2017).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If there's an issue processing one of the overrides (e.g. an
override-specific patch which no longer applies) it helps if devtool
tells you which override it's processing so you can figure out what went
wrong.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
When running devtool modify (or devtool extract) on some recipes (e.g.
db, gdb), since the source comes from a tarball we initialise our own
git repository, but then we move it to another directory. The latter
causes a problem because by default, automatic garbage collection is
enabled and that can be running in the background while we're moving the
repository, which causes the move code to fail as it's trying to delete
files that are already gone. This probably only happens on systems
where /tmp is on a different filesystem e.g. tmpfs. The solution is to
disable the automatic garbage collection when we set up the repository.
(I found this issue by running devtool-stress script.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
build-sysroots and signing-keys aren't really suitable for use with
devtool modify or devtool extract, so just exclude them by default.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Currently the "at" recipe in OE-Core has a postfunc on do_patch which
copies files from ${WORKDIR} to the source tree. However, if you run
"devtool modify at" (or "devtool extract at"), then during extraction
before do_patch has a chance to execute, the files it is going to copy
are moved to the local-files directory, so when the postfunc does
execute it fails. At this point the work directory is a temporary
directory so we can simply copy the files rather than moving them and
then the postfunc succeeds.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Add two synthetic tests for devtool modify + devtool finish: first with
multiple source trees side-by-side, and second to test with one as a
subdirectory of the main source tree. These also test devtool finish's
recently added dry-run option and that detects and errors on uncommitted
changes without being forced.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Fix the oe-selftest test to understand that the source will be
found in a "source" subdirectory if the kernel inherits linux-yocto
since there are multiple trees extracted.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
devtool now handles multiple source trees for any recipe that includes
them in SRC_URI, extracting them all side-by-side so that you can make
changes in any of them. As a result, when running devtool modify on a
linux-yocto kernel recipe under the source path you will get a "source"
subdirectory containing the kernel source and a "kernel-meta"
subdirectory next to it containing the kernel metadata. (Previously you
just got the source tree and the kernel metadata remained in the work
directory). We create a symlink automatically at do_unpack from the work
directory so that it can still be found there, however
kernel_feature_dirs() expects to find the kernel-meta repository and
we also now need to make externalsrc remove that so that it doesn't
unpack and overwrite the one we've already extracted. Change
kernel_feature_dirs() so that if there are no kmeta entries in SRC_URI,
it will fall back to a directory named ${KMETA} if it happens to be
present in the work directory, ignoring how it got there.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If you have multiple source trees being extracted to the work directory
within a recipe (e.g. you have two tarballs referred to in SRC_URI) and
one isn't being extracted into the other, then devtool failed to extract
all the sources because it only took the source tree that S pointed
into. To fix this, we need to take a look at the work directory after
do_unpack and see if there are any additional subdirectories; if so we
need to put the main source tree in a subdirectory and put the
additional subdirectories next to it. We also ensure that symlinks from
the work directory get created at the end of do_unpack to point to
these (so that references in the recipe continue to work).
In addition to multiple source trees at the work directory level, this
patch also handles multiple nested git trees (where you have multiple
git URLs in SRC_URI with one or more inside another). These caused a
different problem, where changes in sub-repos are not fully captured at
the top level - we need to handle each repo separately.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If patch_recipe_file() is called with output redirection on the same
file twice in succession, then we don't want to wipe out the changes the
first call made so we need to be reading in the redirected file if it
exists instead of the original one.
This is important to enable devtool finish to work with multiple source
trees within the same recipe.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If you use devtool modify, then devtool reset, keep the source tree and
then devtool modify on the same recipe with the -n option to re-use the
existing source tree, we should pick up the commit hashes properly from
the source tree so that later on devtool finish has these to compare to
the commits in the tree at that time. We also need to be careful the
second time around that we only get the original commits rather than the
current HEAD which may be the result of user changes (hence using
"devtool-patched", the tag that was placed at the original HEAD).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The kern-tools-native recipe as it currently stands is unusual in that
it fetches source from a repository but sets S = "${WORKDIR}" which
causes some problems. First you get a failure because we're calling "git
commit" unconditionally even if there are no local files, and there
aren't any in this case which means the commit fails.
After that's fixed, we hit another problem where "recipe-sysroot-native"
subdirectory appears in the extracted source tree. We don't want that so
exclude it from copying.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Use a namedtuple to return information to the caller, since I've been
expanding that information we should avoid having to change all of the
calling code each time.
Additionally, it turned out that a bunch of the callers were checking
for None being returned in the initial_rev value, but that's no longer
possible, so tidy up the calling code.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
writeable
Make the error messages a little more friendly.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
UNKOWN -> UNKNOWN
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Fixed:
- Add a comment in base.bbclass:
def oe_import(d):
import sys
# Comment
bbpath = d.getVar("BBPATH").split(":")
[snip]
Note, '# Comment' is started with '#', it is legal in python's syntax
(though maybe not a good style), but bitbake reported errors:
$ bitbake -p
ERROR: ParseError at /path/to/base.bbclass:20: unparsed line: ' bbpath = d.getVar("BBPATH").split(":")'
This error report would mislead people, the real problem is that '# Comment'
is not supported, but it reports the next line, this may make it hard to debug
the code are complicated.
We can make __python_func_regexp__ handle '^#' to fix the problem, since it
already can handle blank line "^$" in a python function, so it would be pretty
safe to handle "^#" as well.
(Bitbake rev: 79e62eef1c93f742bf71e9f25db57fdd2ffedd02)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #12898]
There might be no bitbake-cookerdaemon.log, print a message for debugging.
(Bitbake rev: 4adc582d2df7fdb9e51c4ebb5e66bbd21165b4dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixed:
Add the following two lines to conf/local.conf:
FOO = "${@foo = 5}"
HOSTTOOLS += "${FOO}"
* Before the patch
$ bitbake -p
Check the first lines of bitbake bitbake-cookerdaemon.log
[snip]
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 125, in python_sub
codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
File "FOO", line 1
[snip]
There isn't a file named 'FOO', but a variable name.
* After the patch
$ bitbake -p
[snip]
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 129, in python_sub
codeobj = compile(code.strip(), varname, "eval")
File "Var <FOO>", line 1
foo = 5
(Bitbake rev: 540b546be55e0f5f5d91695956da3a7732b2f90a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This can make it print clearer errors, for exmaple:
Add Runtime_error to 'def oe_import(d)"
16 def oe_import(d):
17 import sys
18 Runtime_error
[snip]
* Before the patch:
$ bitbake -p
ERROR: Unable to parse /buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py
Traceback (most recent call last):
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 430, in DataSmart.expandWithRefs(s='${@oe_import(d)}', varname='OE_IMPORTED[:=]'):
except Exception as exc:
> raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception NameError: name 'Runtime_error' is not defined
This error message has two problems:
- "Unable to parse data_smart.py": This isn't the real cause.
- It pionts to "raise ExpansionError(varname, s, exc) from exc" which isn't clear enough.
* After the patch:
$ bitbake -p
ERROR: Unable to parse OE_IMPORTED[:=]
Traceback (most recent call last):
File "OE_IMPORTED[:=]", line 1, in <module>
File "/buildarea1/lyang1/poky/meta/classes/base.bbclass", line 18, in oe_import(d=<bb.data_smart.DataSmart object at 0x7f9257e7a0b8>):
import sys
> Runtime_error
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception NameError: name 'Runtime_error' is not defined
This one is more clearer than before.
(Bitbake rev: c0fe524c1aeccb24ddd2e1f7bf235c00fdbf79a7)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixed:
- Define an error anonymous function in base.bbclass:
15
16 python() {
17 Compile error
18 }
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 18:
The code lines resulting in this error were:
0001:def __anon_18__buildarea1_lyang1_poky_meta_classes_base_bbclass(d):
*** 0002: Compile error
0003:
SyntaxError: invalid syntax (base.bbclass, line 18)
The lineno should be 17, but it reported 18, this would mislead people a lot
when there more lines.
- Now fix it to:
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 17:
The code lines resulting in this error were:
0001:def __anon_18__buildarea1_lyang1_poky_meta_classes_base_bbclass(d):
*** 0002: Compile error
0003:
SyntaxError: invalid syntax (base.bbclass, line 17)
This is because the anonymous function is constructed by:
text = "def %s(d):\n" % (funcname) + text
The len(self.body) doesn't include the "def " line, the length of the function
should be "len(self.body) + 1", so we need pass "self.lineno - (len(self.body) + 1)"
which is the same as 'self.lineno - len(self.body) - 1' to
bb.methodpool.insert_method() as we already had done to named function. Otherwise, the
lineno is wrong, and would cause other problems such as report which line is
wrong, but the line is not what we want since it reports incorrect line.
(Bitbake rev: 7466c8765fcc792e5ea3daefda3c5895e782d6c4)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixed:
- Add an error line in base.bbclass, e.g.:
15
16 def oe_import(d):
17 import sys
18 Compile error
19 bbpath = d.getVar("BBPATH").split(":")
[snip]
Note the "Compile error" line, I added it for reporting errors.
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 15:
The code lines resulting in this error were:
0014: import oe.data
0015: for toimport in oe.data.typed_value("OE_IMPORTS", d):
0016: imported = __import__(toimport)
0017: inject(toimport.split(".", 1)[0], imported)
*** 0018:
0019: return ""
0020:
SyntaxError: invalid syntax (base.bbclass, line 18)
There are 2 problems:
- The "line 15" is incorrect, it is a blank line, not the error line.
- The "*** 0018" points to incorrect position.
These two problems would mislead people a lot sometimes.
- Now fix it to:
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 18:
The code lines resulting in this error were:
0001:def oe_import(d):
0002: import sys
*** 0003: Compile error
0004: bbpath = d.getVar("BBPATH").split(":")
[snip]
SyntaxError: invalid syntax (base.bbclass, line 18)
Please see comments in the code for more details on how it is fixed.
(Bitbake rev: bbb3d87d171da38fd8e9bce011d109fba28a75c0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The colors specified for use with bitbake-diffsigs were adapted for a
dark theme, e.g., by setting the background color to black, which made
it look very bad when used with a light theme.
To make it look good both with a dark or a light theme, it is better
to drop the background color. It is also better to leave out the color
altogether for the title and just use bold. Finally, dropping bold for
the red and green texts indicating removed/added values better matches
other colorized diff implementations as, e.g., git diff.
(Bitbake rev: f1a2c23520832ee91e85338c1ad8af1fec0d0b19)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 2c858a2e1c8c99f87e74c2f95ccc749edfbe01ac)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: f08f09accc124162e7538595694868d307c59649)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 54b58dab8c76279ef7f9d2bd8ec1018dbcdf958b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: f69b41b0796a9ce5716f794b8e9fc3be7ea96b68)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: de796789d386ec0e4f67455b07cf80df5324d897)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Drop backported patch already applied upstream.
(From OE-Core rev: 7399dd25bcd81e61dca21bd187aa7217231eb8c4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 1df9f7d6946c9a0ee0749ed8646446eb56878846)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: e06afc5cc6d848e63e1dd66425612c6a486a5a6c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Upgrade harfbuzz from 1.8.8 to 1.9.0.
(From OE-Core rev: 55a2d8619b0a3e5606076808d306cd78cf3edf41)
Signed-off-by: Hong Liu <hongl.fnst@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
New patches
* 0001-statx-fix-compile-errors.patch
Rebased patches
* 0039-commands-ar01-Fix-for-test-in-deterministic-mode.patch
Removed removed (accepted in upstream)
* 0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch
* 0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch
* 0043-open-creat-skip-S_ISGID-check-on-files-created-by-no.patch
Removed patches (different fix accepted in upstream)
* 0001-mmap15-mips64-return-EINVAL.patch
(From OE-Core rev: 439cb0421570e1edea6994775ed782b9b264f4a1)
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 750e03a231eb3bcf31c30cf67ff80a6bc821ee66)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: ea4882b89500d9da8d7a731968ea7a311737f6ea)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: c3d863f4f989461c61e7d61259423fe0e8202eed)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: f62a87b3c6638c6da764d19133eba552f2102bae)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 4508d6f0befb1b91f9cfe74b0ca84c8fb5f79da5)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: aedec50bc8fb2ddcd1ea7cadbdd07f9d103840aa)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 22e124ef0b01c3aae75e8e29a3078cb42a47ae17)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 63753e9c06641025ba4711af61a4f34e2388ec72)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: df2a0fd27a23ece636c018d007e2dcf9343fb7a8)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Paul Eggleton
Robert Yang
Peter Kjellerstedt
Ross Burton
Richard Purdie
Hong Liu
Petr Vorel
Carlos Rafael Giani