Ross Burton [Thu, 22 Nov 2018 14:05:16 +0000 (14:05 +0000)]
openssl: don't disable the AFALG engine based on host kernel
Whether the AFALG engine (use of hardware crypto via AF_ALG) is enable or
disable depends on whether the host kernel is 4.1 or above, which has no bearing
on whether the target system supports it.
Remove the complicated logic and simply enable/disable as requested.
Alexey Brodkin [Thu, 22 Nov 2018 12:06:00 +0000 (15:06 +0300)]
gcc: Select proper ARC CPU when build for target
By default GCC for ARC is configured with ARC700 CPU.
This means when we don't pass "-mcpu=xxx":
a) Code will be compiled for ARC700
b) Libs will used for ARC700
And if we happen to run on ARCv2 core like ARC HSxx we
won't be able to use target gcc w/o "-mcpu=xxx" which
is not very convenient as we want to build "target" toolchain
but not canadian-cross.
Note the trick here is we set TUNE_PKGARCH in just 2 values,
it is either "arc700" for all ARCompact cores (ARC750 & ARC770)
and "archs" for all ARCv2 cores (ARC HS38 & HS48), see [1].
This gives us usable defaults.
For cross-compilation we use TUNE_CCARGS for fine-tuning depending
on which HW features we have on the current target so that
we may have HW feature A & B or B & C or A & B & C, see [2].
Robert Yang [Thu, 22 Nov 2018 11:51:59 +0000 (19:51 +0800)]
sstate.bbclass: set SSTATE_EXTRAPATHWILDCARD explicitly
The glob.glob("/sstate/*/*/") is very time consuming, set
SSTATE_EXTRAPATHWILDCARD explicity to avoid that. This can save a lot of time
when there are many sstate files.
For example, I have more than 600,000 sstate files:
* Before
- Without disk caches
$ time python3 -c 'import glob; glob.glob("/sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_populate_sysroot.tgz*")'
real 4m32.583s
user 0m5.768s
sys 0m12.892s
- With disk caches
$ time python3 -c 'import glob; glob.glob("/sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_populate_sysroot.tgz*")'
real 0m4.111s
user 0m2.348s
sys 0m1.756s
* After
$ time python3 -c 'import glob; glob.glob("/sstate-cache.bak/universal/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_populate_sysroot.tgz*")'
- Without disk caches:
real 0m7.928s
user 0m0.172s
sys 0m0.124s
- With disk caches:
real 0m0.131s
user 0m0.088s
sys 0m0.044s
We can see that it saves about 3.8s with disk caches, and saves about 264s
without disk caches.
Mike Crowe [Thu, 22 Nov 2018 10:14:08 +0000 (10:14 +0000)]
terminal: Cope with unreleased versions of tmux
When tmux is built from a non-release Git version, its version number is
"next-X" where X appears to be the expected version number for the next
release. For example, when built from the current state of master, running
"tmux -V" yields:
tmux next-2.9
Currently check_tmux_pane_size only checks for the version being less than
1.9, so it seems unfair to fail with an obscure Python error in this case.
Let's just use the version number after the "next-" prefix if it is
present.
The "image_types" class is now inherited mandatorily in
image.bbclass through the variable IMGCLASSES. Users do not
have to inherit it in their customized image type bbclass.
They also do not have to put it in IMAGE_CLASSES.
Scott Rifenbark [Tue, 13 Nov 2018 18:13:20 +0000 (10:13 -0800)]
ref-manual: Added cross-references to "Post-Installation Scripts"
Two areas in the migration chapter discuss the post-installation
behavior when you defer the scripts to after boot. I added a
couple references to each of those migration note sections that
go into the dev-manual's section.
Scott Rifenbark [Fri, 9 Nov 2018 20:30:33 +0000 (12:30 -0800)]
ref-manual: Added KERNEL_ARTIFACT_NAME and adjusted referencing variables.
The KERNEL_ARTIFACT_NAME variable is used throughout to set the names
of build artifacts. Rather than repeat informaiton about
KERNEL_ARTIFACT_NAME in the many variables that use it, I added
a new entry for the variable. This also impacted the descriptions
of the variables that were repeating information. I updated those
variable descriptions as well.
Scott Rifenbark [Tue, 6 Nov 2018 18:31:08 +0000 (10:31 -0800)]
ref-manual: Added KERNEL_IMAGE_NAME description
The KERNEL_IMAGE_NAME variable is new and is effectively
a renamed KERNEL_IMAGE_BASE_NAME variable now. I provided a
new glossary description for the new variable. I updated the
existing KERNEL_IMAGE_BASE_NAME description to note it has
changed. We can't just delete the old variable as there are
migration notes for previous releases of YP.
Scott Rifenbark [Tue, 30 Oct 2018 19:14:55 +0000 (12:14 -0700)]
ref-manual: Updated testimage and testsdk class descriptions.
I added notes indicating that the best practice for automated testing
is to inherit these classes by using the IMAGE_CLASSES variable instead
of the INHERIT variable.
Remove upstreamed patches.
Add a tweak to 0001-When-building-introspection-files-add-CMAKE_C_FLAGS-.patch
for Javascriptcore gir file (previously it was pre-compiled in tarballs).
bitbake: fetch/git: fix AttributeError in shallow extraction logic
This code checks to see if shallow is either disabled or the tarball is
missing, but the else block tries to print the tarball filename, and
this attribute doesn't exist at all when shallow is disabled. Handle the
two cases separately to give sane errors for both cases without the
exception:
Exception: AttributeError: 'FetchData' object has no attribute 'fullshallow'
When multiconfig is enabled the cooker adds providers
for all the targets to be built on all the multiconfig
variables that were set, regardless if there is a dependency
to it or not.
This causes an issue when a certain target is incompatible
with one or more of the multiconfigs, e.g. the target is not
in COMPATIBLE_MACHINE for one of the MACHINEs being built,
causing the cooker to error out since no providers can be
found for that certain target on that multiconfig.
This patch modifies the behavior to only look for PROVIDERS
for a target on the multiconfig that was selected to be built,
PROVIDERS are then looked for in other multiconfigs only when
there is a defined dependency to them.
Joshua Watt [Wed, 21 Nov 2018 16:37:05 +0000 (10:37 -0600)]
poky.conf: Include SDKMACHINE in SDK name
Replace SDK_ARCH with SDKMACHINE so that SDK targeting different
development machines but having the same architecture don't cause
similar errors as found in '3614dd4aee9 ("poky.conf: Add MACHINE to
SDK_NAME")'
This doesn't have any effect on the SDK machines provided in oe-core,
since SDK_ARCH is the same as SDKMACHINE for all of them.
ERROR: core-image-sato-1.0-r0 do_populate_sdk: The recipe core-image-sato is trying
to install files into a shared area when those files already exist. Those files and
their manifest location are:
deploy/sdk/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.6+snapshot.host.manifest
(matched in manifest-qemux86_64x86_64-core-image-sato.populate_sdk)
deploy/sdk/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.6+snapshot.testdata.json
(matched in manifest-qemux86_64x86_64-core-image-sato.populate_sdk)
deploy/sdk/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.6+snapshot.target.manifest
(matched in manifest-qemux86_64x86_64-core-image-sato.populate_sdk)
deploy/sdk/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.6+snapshot.sh
(matched in manifest-qemux86_64x86_64-core-image-sato.populate_sdk)
Please verify which recipe should provide the above files.
Adding MACHINE to the artefact name will avoid this. The issue was highlighted by
changes to the autobuilder configuration.
shrinkwrap resolved relative URL can start with http. For example,
"resolved: http-proxy/-/http-proxy-${PV}.tgz" is still relative URL
to npm registry, but starts with http.
Current if statement compares the startswith 'resolved' to 'http',
which makes impossible to use npm download. Condtional comparison
now strictly checks for "http://" and "https://"
Joshua Watt [Tue, 20 Nov 2018 20:04:15 +0000 (14:04 -0600)]
meta/icecc.bbclass: Move system blacklist to variables
The system blacklists are moved to variables which are ignore when
hashing. This prevents changes to the blacklists from causing all
taskhashes to change (and thus rebuild).
Joshua Watt [Mon, 19 Nov 2018 18:11:13 +0000 (12:11 -0600)]
classes/testsdk: Split implementation into classes
Splits the SDK test implementation into configurable Python classes. The
classes used for the normal and extensible SDKs are
${TESTSDK_CLASS_NAME} and ${TESTSDKEXT_CLASS_NAME} respectively.
This allows SDK machines to override the classes used to implement the
tests. For the traditional SDK, a common "run()" function is provided by
the class (oeqa.sdk.testsdk.TestSDK), with several hook member functions
that can be overridden in child classes, making it easier to have
consistent behavior. The extensible SDK class
(oeqa.sdkext.testsdk.TestSDKEXT) also has a common "run()" function, but
no hooks have yet been added as there is not currently a known use case
for create derived classes.
These changes should be purely organizational; no functional changes
have been made to either the standard SDK or extensible SDK tests.
Jens Rehsack [Sun, 18 Nov 2018 18:36:46 +0000 (19:36 +0100)]
pseudo: fix link of sqlite3 using pkg-config
If sqlite3 is built with FTS5 it uses log() from libm, it sqlite3 is built
with READLINE it uses tgetent from a curses lib and readline from libreadline,
if it is built using deflate from libz ... , but all that linkage is lost
if we manually statically link so explicitely extract extra static linking
options from pkg-config and force them into pseudo as well.
This commit obsoletes (so include the implicit revert) e39fec613d pseudo: fix link with new sqlite3
Jens Rehsack [Sun, 18 Nov 2018 18:36:31 +0000 (19:36 +0100)]
sqlite3: Update 3.25.2 -> 3.25.3
Update SQLite3 from 3.25.2 to 3.25.3 to fix following issues:
* Disallow the use of window functions in the recursive part of a CTE.
* Fix the behavior of typeof() and length() on virtual tables.
* Strengthen defenses against deliberately corrupted database files.
* Fix a problem in the query planner that results when a row-value
expression is used with a PRIMARY KEY with redundant columns.
* Fix the query planner so that it works correctly for IS NOT NULL
operators in the ON clause of a LEFT JOIN with the
SQLITE_ENABLE_STAT4 compile-time option.
Also introduce PACKAGECONFIG tunables to enable/disable e.g. index
and search functions to allow shrinking the library for very small
targets.
Hongxu Jia [Mon, 19 Nov 2018 13:34:56 +0000 (08:34 -0500)]
go-target.inc: fix go not found while multilib enabled
Go binaries were installed to ${libdir}/go/bin, and create symlink
in ${bindir}, while enabling multilib, libdir was extended (such as
/usr/lib64), but BASELIB was not (still /lib), so use
baselib (such as /lib64)) to replace
Richard Purdie [Mon, 19 Nov 2018 15:24:09 +0000 (15:24 +0000)]
lttng-tools: Upgrade 2.9.5 -> 2.10.5 and improve ptest
A backported patch was removed.
The kmod option changed format in the new version so was adjusted accordingly.
The ptest package was improved to resolve failures in the tests/unit/
directory but disabling attempts to rebuild the binaries on target.
Various ptest libtool script wrappers are now replaced with real binaries
and since the test suite knows about these paths for dymanic libraries,
we put links in place for those.
A data file needed by one of the tests is also copied in.
Richard Purdie [Mon, 19 Nov 2018 15:14:11 +0000 (15:14 +0000)]
lttng-tools: Improve ptest robustness
There are some fatal make errors that occur from the current ptest
for lttng-tools however since other tests are successful, those make
build failures were being ignored.
When upgrading, the order of test execution changed and the ptest failed
fatally straight away with the same errors.
Passing -k to make means it will try and run all the tests making the
test suite run more consistently over all lttng-tools versions.
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.
Robert Yang [Wed, 14 Nov 2018 09:46:39 +0000 (17:46 +0800)]
bitbake: data_smart: fix filename for compile()
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
* 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
Robert Yang [Wed, 14 Nov 2018 09:46:37 +0000 (17:46 +0800)]
bitbake: parse/ast: fix line number for anonymous function
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: siggen: Adapt colors used by bitbake-diffsigs to support light themes
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.
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
