Douglas Royds [Thu, 22 Nov 2018 20:41:57 +0000 (09:41 +1300)]
reproducible: Don't look for youngest file when no source tarball
Some packages (eg. init-ifupdown) take their source files entirely from
openembedded-core, that is, they download no source tarball.
These recipes either don't use S at all (ie. it is empty at unpack time),
or they set S = WORKDIR (as in init-ifupdown).
Looking at the file timestamps in the WORKDIR causes a non-reproducible
SOURCE_DATE_EPOCH, as files taken from file:// URIs do not have
reproducible timestamps.
If S == WORKDIR, we are better to assume that there is no source tarball,
and to fall back to a fixed timestamp for the SOURCE_DATE_EPOCH.
This makes the init-ifupdown build reproducible.
Paul Eggleton [Thu, 22 Nov 2018 21:55:50 +0000 (10:55 +1300)]
socat: fix LICENSE
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).
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
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
