It is possible to inherit meta data for either patches + config
or for just config.
It is possible that the patch queue contains invalid (when
sourced) shell characters in the patch names, which throws a
syntax error and aborts processing.
The patch + config case was fixed some time ago, but we recently
stumbled onto the config-only case which was still not properly
quoted and hence safe.
This commit brings the config-only inherit in line with the
patch + config processing and we won't abort processing if
characters like () are in patch names.
(From OE-Core rev: ce7044be10597d53725e6917a2949f3ab3de0c96)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Making the following kernel configuration fragment changes available:
c9f07d79f01d nftables: add more configuration options.
8d3cf0ad6c0c common-pc-wifi.cfg: add CONFIG_MT7601U module
55c9bf749c6d ktypes/developer: Enable CONFIG_KEXEC in config
(From OE-Core rev: a0d24f69425716ffd2439b1fb9170c343eaca453)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If for any reason the parse_recipe fail in extract command
the process gets locked because Cooker is expecting the
finish event by tinfoil.
For example:
$ devtool extract remake /tmp/remake
ERROR: remake is unavailable:
remake was skipped: PREFERRED_PROVIDER_virtual/make set to make, not remake
(From OE-Core rev: 2c0062b59178fa668b26487b6d2f1e81a0d868e0)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently there was a restriction to only execute tests that's
inherits from OETestCase but in some circunstancies the features
from the OEQA framework isn't needed so we need to support
basic unittests.
[YOCTO #10828]
(From OE-Core rev: baac26f1b36e89e07637b738dd31ec7356f05a02)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our filtering allows to specify which tests to run using,
<module_name>.[test_class].[test_name]
But the module name logic was restricted to only accept one level,
for example: runtime_test vs oelib.types, to support multiple
submodules use only the first part for filtering.
This allows to run the whole tests in a module with more than tree
levels.
Due to the ambiguity on the test filtering options with test cases
with more than tree levels the supported sytnax is,
<module>
or
<module>.[submoduleN].[test_class].[test_name]
[YOCTO #11632]
(From OE-Core rev: cf2ee12b007e5570959ccfbb643159b21d90426e)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To make it obvious what is lost when python is disabled, actually delete the
scripts so the user can't attempt to use them.
(From OE-Core rev: 25c8d738b904c8755df203122067afa0047b27ad)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These commands are not whitelisted by the HOSTTOOLS variable which
silently prevents the MBR disk signature from being written to the
image.
Reported-by: Michael Davis <michael.davis@essvote.com>
(From OE-Core rev: a58e53f55259acd79a98a0f8b8a435d2a5aef36e)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since do_rootfs depends on cve-check results of all recipes,
we need to recursively depend on recipe do_cve_check.
(From OE-Core rev: a1af526e43cb476472a6203882c12deef297f542)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes there are control messages in cve-check-tool printed to
stderr. These lead to parsing error and thus failed build.
This can happen for instance when cve database needs to be
refreshed during build.
(From OE-Core rev: 6d8a17f4c50be292990e37de65630a6b84466ee6)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there is cve report for a recipe in previous build and there
is no result for current one, old cves are kept in CVE_CHECK_DIR.
This happens on version upgrade or when cve/recipe is whitelisted.
(From OE-Core rev: 85b4941c71a0e3c08a8c48d52a94dfe2897d2c92)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.
(From OE-Core rev: 7a47752f8223f3c0ed4354d5e39f1319071acf41)
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means mismatched layers are more clearly identified to the user in
cases where compatibility has not been tested. This is perhaps not as
needed for the core repository (other than CORENAMES) but lets lead by
example.
(From OE-Core rev: cde66d5eac8e5c2821ba225dc4be4af4e0581652)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, someone trying a master branch of any given layer may
or may not find it works with the version of OE-Core that they
have picked.
This patchset introduces LAYERSERIES_CORENAMES and
LAYERSERIES_COMPAT_<layername> with the intention of allowing layers
to indicate which versions of the core project they're compatible with.
In general the master branch will use the next release codename as
the value of LAYERSERIES_CORENAMES, meaning that the waterfall model
of layer releases is supported with layers updating their
LAYERSERIES_COMPAT_ values as they branch for release.
Both variables support multiple strings and a given layer is accepted
if there is overlap of any one value. This means a layer can be compatible
with multiple core versions.
Setting LAYERSERIES_COMPAT_ will be required by the Yocto Project
Compatible v2 standard but the system will not error if its not set at this
point.
This should make it clear when a given layer is unmaintained and untested
with new releaes of OE-Core, a common user pain point.
(Bitbake rev: 92c49b9b1a16dfd35444db8143bd4cae4cda70cc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tinfoil sets up its own logger by default, but if and when we initialise
the UI (by default knotty) will also set one up, leading to duplicated
messages specifically from tasks. To avoid this, rather than adding some
kind of parameter, just check if there is already a logger outputting to
stdout/stderr and if so, skip adding our own.
Part of the fix for [YOCTO #11275].
(Bitbake rev: 66d866745f35468d1540a793d07e3a401298b84b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding an additional logger in setup_bitbake() interacts poorly with the
logger we have added by default in tinfoil's constructor, with the
result that messages may be doubled or even tripled in tinfoil-using
scripts. Disable adding this one when calling setup_bitbake() from
tinfoil to avoid this problem.
Part of the fix for [YOCTO #11275].
(Bitbake rev: 8a5bae76f91f2411187c638a42fa3c762052cf11)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop a number of the commands and support functions that were created
solely to support functionality in the now-removed Hob UI. In most cases
we now have this functionality elsewhere e.g. to modify config files and
recipes we have bb.utils.edit_metadata_file() and friends, and in OE we
have oe.recipeutils.patch_recipe_file() and friends which build on top of
the former. Additionally, some of it represented pretty egregious
incursion of OE metadata-specific references into BitBake code.
For now I have left in the find*File functions and commands as they are
relatively generic and possibly still useful, but they might be removed
in future.
(Bitbake rev: a322f13183c66a28d93cc4bc3d839d95fc1d90f4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OpenEmbedded's buildhistory class we want access to the bitbake
command line that launched the build, and up to now we were simply using
sys.argv from within the event handler to get that. Unfortunately that
doesn't work in memory resident mode, since the event handler is
naturally executing within the server and thus will give you the command
that launched the bitbake server which is much less interesting. Add a
dynamic variable BB_CMDLINE to provide access to this, set from sys.argv
within the UI process in updateToServer().
(Note that BB_CMDLINE isn't currently passed through to the worker, so
this is only really readable from event handlers plus any explicit
getVariable calls - in theory an observe-only UI could read it for
example.)
Part of the fix for [YOCTO #11634].
(Bitbake rev: 8ad31a3eff5cfcb7b1c462578a582dafcbc426d4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we set these flags here then we can not only tidy up some of the code
that calls initConfigurationData() (and reset() which simply calls the
former), we also avoid calling initConfigurationData() an extra time
unnecessarily during startup (since setting baseconfig_valid = False in
updateConfigOpts() also resulted in initConfigurationData() being
called from updateCacheSync() at the end of the command.)
(Bitbake rev: 74d2ef99a920aa9e70470ba8e600ea973a3c672a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you build a recipe, modify one of the files referred to in SRC_URI,
then build it again, it should re-run do_fetch and the tasks that depend
upon it to incorporate the modified file. With memory resident mode this
was not working unless you restarted the server, because the mtime of
the file was cached and thus we never checked the actual file. Clear out
the mtime caches in buildTargets() to ensure this isn't an issue. I did
a minor refactoring to break this out to its own function since we were
already clearing out the build mtime cache here.
(The test I used for this was . ./oe-init-build-env-memres,
bitbake -c fetch mdadm, modify the comments at the top of one of the
patches referred to in the recipe, and then bitbake -c fetch mdadm again
and it should re-execute the fetch task ("... 0 didn't need to be
re-run".)
Fixes [YOCTO #10732].
(Bitbake rev: fe4f3487368bc35043a1ba464e1c69d2c9cbefc6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CookerConfiguration sets the "tracking" option to True when -e is
specified in order to have history tracking enabled in the datastore
so that we can show variable history (which isn't enabled by default for
performance reasons), however in memory resident mode this wasn't doing
anything because it was happening on the UI side only. We do have a
mechanism for updating the cooker configuration in the server, but the
tracking option wasn't being included in the list of options we updated,
so we just need to add this option to fix the issue.
Fixes [YOCTO #10730].
(Bitbake rev: 57d4977555cf892b15dd0302dfe261fe37d49327)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using 1000000 memory address for kernel and a00000 for dtb
can cause kernel image to overwrite dtb when uncompressing
and u-boot crashing with:
ERROR: image is not a fdt - must RESET the board to recover.
Updated flashing instructions for the board to use addresses
1000000 and 2000000 to avoid this error.
Got rid of resetting loadaddr and ftdaddr u-boot variables.
(From meta-yocto rev: 05fc7fc19a9b43cab31ea873e5c38a2737c799cf)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SMP kernel config presents issues on qemuarm because:
CONFIG_SMP=y
Dependencies Missing:
- CPU_V6K or CPU_V7:
These are selected by setting:
CONFIG_ARCH_MULTI_V7=y
or
CONFIG_ARCH_MULTI_V6=y
But our QEMU + ARM BSPs are based on armv4/v5 hence they are
incompatible with CONFIG_SMP.
This patch fixes the script, and avoids offering SMP to the user
when the created BSP is based on QEMU + ARM.
[YOCTO #11426]
(From meta-yocto rev: d63aa4acd20b2aa022701289e9ab7be7f551b0b2)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BBFILES_DYNAMIC can be used to activate content only when some other
layers are present. The other layers are identified by the collections
that they define.
The main use case is to avoid .bbappends without the corresponding .bb
file in layers that want to modify other layers via .bbappends without
introducing a hard dependency on those other layers. .bb files could
also be handled via BBFILES_DYNAMIC.
Entries in BBFILES_DYNAMIC must have the form <collection
name>:<filename pattern>. Example usage:
BBFILES_DYNAMIC += " \
clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
"
Parsing is aborted when invalid entries are found with an error
message like this:
ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
/work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
/work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
Based on a patch by Richard Purdie.
(Bitbake rev: 04f8bd50aa04b12cf91dd6a3154527ad2c24695c)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This vulnerability is also called "rpcbomb".
Backport upstream patch to fix this vulnerability.
CVE: CVE-2017-8779
(From OE-Core rev: d10edb97f0a7d6952adf9e0dbb6b4d5c0d168195)
Signed-off-by: Fan Xin<fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Upgrade libtiff from 4.0.7 to 4.0.8
2. Delete the following patch file due to CVE-2017-5225 has been fixed in 4.0.8
libtiff-CVE-2017-5225.patch
(From OE-Core rev: 825927e85933322e6f195f0d937359017a9a9b97)
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Upgrade hdparm from 9.51 to 9.52
2. Update the checksum of LIC_FILES_CHKSUM
The following content is appended to LICENSE.TXT, the licence is still BSD & GPLv2.
The apt.c file is Copyright (c) 2009 Jan Friesse <jfriesse@gmail.com>.
You may use/distribute apt.c freely, under the terms of either
(your choice) the GNU General Public License version 2,
or a BSD style license.
(From OE-Core rev: 3cd7aa486527d34bf6d20dd37046fe683230a4b6)
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is wrongly detected by configure since it only checks for
__sync_add_and_fetch and not __atomic_fetch_add, it decides
to let compiler emit references to atomic functions which
it expects to be provided by libgcc, but thats not the
case for armv5 arch
[YOCTO #11616]
(From OE-Core rev: 6866ad53c5d49781002470195b4aae1ad1afde5c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix build when PIE is turned on. It tries to build
.so file using -pie and -shared flags together because
its doing compile and link in same step CFLAGS and LDFLAGS
are combined and does not work, ending in errors e.g.
| /mnt/a/oe/build/tmp/work/cortexa7t2hf-neon-vfpv4-bec-linux-musleabi/python-pygpgme/0.3-r0/recipe-sysroot/usr/l
ib/Scrt1.o: In function `_start_c':
| /usr/src/debug/musl/1.1.16+gitAUTOINC+179766aa2e-r0/git/crt/crt1.c:17: undefined reference to `main'
| collect2: error: ld returned 1 exit status
This error while cryptic is due to the fact that we are
building a shared library but also pass -pie flag to the link
step after specify LDHSARED ( which is -shared linker flags )
we can not use -pie when doing shared libs. This is true for all the python
modules inheriting setup tools
Disable the pie flags thusly for all modules using setuptools since
this setting is done in setuptools makefiles which are then used
during module compiles
(From OE-Core rev: 6a4e3b696d32809279f1550cc1d67bc6b9979a03)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe explictly sets -DAO_USE_PTHREAD_DEFS on ARM, but with libunwind 1.2
this causes the linker to fail:
hidden symbol `__sync_synchronize' in libgcc.a(linux-atomic.o) is referenced by DSO
Removing these defines lets configure do the right thing and build libunwind.
(From OE-Core rev: f2efadab8b1ab1c50584a39908673e1a6717f753)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield
Tanu Kaskinen
Denys Zagorui
Aníbal Limón
Ross Burton
Jonathan Liu
Peter Marko
Khem Raj
Jan Kiszka
Martin Kelly
Richard Purdie
Ming Liu
Paul Eggleton
Ed Bartosh
Alejandro Hernandez
Patrick Ohly
Fan Xin
Joe Slater
Chen Qi