Without this, error output such as that in the teardown can be lost
and processes may recieve signals they're not expecting causing other
strange errors.
(From OE-Core rev: 1e3f44737a15feb3128ba7fc0dbe896dd8782e07)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has been an opt-in for so long, some distributions e.g.
poky-lsb uses it by default however, since most of linux
distros have started to default to these settings for security
enhancements, time has come for OE to make it default too
(From meta-yocto rev: 81bf1019c8601da952242fbcc827e0bef1ff25d7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is in default distro config now
(From meta-yocto rev: c85fa6a397d7ed97779ce347d4013cd1ea99d53f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since `6146b8c glibc: Disable crypt support in glibc' in oe-core,
python2/3 could not find symbol crypt which caused import crypt failed.
[snip]
>>> import crypt
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.5/crypt.py", line 3, in <module>
import _crypt
ImportError: /usr/lib64/python3.5/lib-dynload/_crypt.cpython-35m-x86_64-linux-gnu.so: undefined symbol: crypt
[snip]
Add virtual/crypt to DEPENDS, and python's build system (setup.py)
will search libcrypt.so in recipe-sysroot and add `-lcrypt' if it
exists.
(From OE-Core rev: d2a929d932900f753af1a06a8cb98d953369e3b4)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
remove the indirect dependcy of autoconf-archive-native via
SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed
into sysroot, which may cause compile problem.
(From OE-Core rev: d23156460e2b8f6684bd3005d7fa09b2c73e522e)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running this test case, we will see the following error.
AttributeError: type object 'BuildAssimp' has no attribute 'project'
assimp.py test case does not make use of SDKBuildProject, so remove
the import statement and the tearDownClass.
(From OE-Core rev: ca0a40a852abed981d54503ef2d86708471c821e)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LLVM_TARGETS_TO_BUILD is needed to represent HOST_ARCH for
builds and target specific additions should use class-target
override
(From OE-Core rev: 5e6e08512e130951e66376ea43e4e6a98941b950)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Import from meta-oe layer
- This is useful for many packages where CR-LF
needs to be adjusted, many recipes depend on it
e.g. meta-multimedia libebml and so on.
- Add myself as maintainer for now
(From OE-Core rev: d8c075d9ac8792726be162da02f2325cbb3aeaaa)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use CPPFLAGS instead of CFLAGS since there is C++ compiler being used for somefiles
Fixes
gdb/gdbserver/../../../gdb-8.1.1/gdb/gdbserver/../common/common-utils.c:419: undefined reference to `rpl_stat'
| collect2: error: ld returned 1 exit status
| make[4]: *** [Makefile:414: libinproctrace.so] Error 1
(From OE-Core rev: d6806b449ba8b44fd74dfb05c65b9233b6f3ace5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to avoid confusion with "type" command in shell
(From OE-Core rev: 8d454ea754c96561257b1cc011fa638ceaa771db)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* some people don't like the ${MACHINE} in the symlink, because now the DEPLOYDIR already
contains ${MACHINE} subdirectory, add KERNEL_ARTIFACT_LINK_NAME variable to change it
in one place without the need to list all variables for various artifacts
(From OE-Core rev: 416b58d84f1124212f114198d2fcb1f3a9bbd223)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* for consistency with other artifacts variables, include only the version string, not the actual name or extension
* changing .tgz to something else in the MODULE_TARBALL_NAME variable only wouldn't make much sense
because then kernel.bbclass still calls "tar -cvzf" to create it
(From OE-Core rev: 43bd7f39157da49f7fb0c2d6d9751059471c8d53)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* for consistency with IMAGE_NAME and IMAGE_LINK_NAME
and to avoid confusion with IMAGE_BASENAME (which is the
actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME
was only the version suffix)
(From OE-Core rev: f952c8e08b4798aa0f8bf764cfd70bda0eae9b8b)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use the same naming scheme for fitImage files like all other deployed artifacts
* remove unnecessary cd to DEPLOYDIR
* remove unnecessary cd to B
(From OE-Core rev: fd69f8b2d7dd950cee9e820ef91ea90521c95ace)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this makes it easier to use different version string than DATETIME, e.g. set from jenkins job
while keeping the suffix consistent across all artifacts stored in DEPLOYDIR
(From OE-Core rev: 1245935b9bf32e0321d8ff12492983ba8506190a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The testdata.json is being written to DEPLOY_DIR_IMAGE directly,
thus bypassing sstate, which results in an ever growing list
of files.
Write them to IMGDEPLOYDIR instead, so as to benefit from the
automatic management via sstate.
(From OE-Core rev: 1f7399a5e5d12b7ca3faf399a70c1613d522c28d)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test in SDK was failing to execute:
$ autoreconf --install --force
due to missing perl modules. Add the needed perl modules
for target build:
perl-module-bytes
perl-module-thread-queue
perl-module-threads
Duplicate the perl module dependencies for SDK as well.
Now autoreconf runs with a trivial example.
(From OE-Core rev: 71764105510e2a98150f63aae0ada1600ad33041)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Automatically select one kernel type image based on a predefined
precedence list if there are multi kernel images installed.
(From OE-Core rev: d1d80566681d4cdc00aa3d4b5e4bcf5edb7132b7)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support to specify a custom extlinux.conf via something like:
bootloader --configfile="extlinux.conf"
(From OE-Core rev: 33f85c8bf80d70f00eeccd9ab3dfa417c0fc7df1)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When systemd start the weston.service, the script "weston-start" will
check if the dir "XDG_RUNTIME_DIR" (usually is /run/user/0) exits and
create it. Then weston will create a socket file "wayland-0" for communications
with clients in this dir.
If systemd is built with enabling "pam" feature, the login will call "run-user-0.mount"
to mount tmpfs at the dir "/run/user/0", then the socket file "wayland-0" will be
missing since it is created in the old "/run/user/0".
So add "PAMName=login" to let weston.service call login first, once tmpfs is mounted at
"/run/user/0", then call weston-start to create a socket file in it.
(From OE-Core rev: 3cb303ffee8610d41c9a0745d366556c24066bc3)
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The aarch64 build issue in the afalg engine appears to have been
fixed upstream since openssl 1.1.0g:
a0c262644e
(From OE-Core rev: 3184de7f57c05f32682d0c00baf797074b137422)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A single version of the openssl.sh environment-setup script is
currently shared by both the openssl 1.0 and 1.1 recipes. The libdir
path in the script needs to be tweaked for openssl 1.1.
(From OE-Core rev: 950f89a5eb98edbd734247b4141e18e635ef4f91)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The openssl 1.0 recipe puts the libdir symlink to /etc/ssl/openssl.cnf
in the base openssl package (along with the libdir symlinks to
/etc/ssl/certs and /etc/ssl/private). Keep the openssl 1.1 recipe
aligned with that approach until there's a clear reason to do
something else. For more background, see comments in the following
thread:
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135176.html
(From OE-Core rev: 480335803928c95e7948f8c949127ccb5cbc7dbe)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The openssl 1.1 recipe doesn't have a PACKAGECONFIG option for perl,
so the RDEPENDS for openssl-misc shouldn't be conditional on it.
(From OE-Core rev: 6c6c3809b9db3a08eefabe06d3f35cee5f400d92)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Formatting and comment tweaks only, no functional changes.
(From OE-Core rev: 06da559b5becee1b5fcc2263f6edd95f6d305fc2)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to comments in Configurations/10-main.conf, the linux-elf
target is "... to be used on older Linux machines where gcc doesn't
understand -m32 and -m64".
The linux-x86 target appears to be the newer replacement (currently
the only difference between the two is that linux-x86 adds -m32 to
cflags).
(From OE-Core rev: 9e9d0045caa62f3dba2760460de4e6eac38b4628)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Merge duplicates + minor reformatting (no functional changes).
Note that the openssl 1.1 recipe still needs to be updated to handle
MIPS Release 6 ISA targets (e.g. linux-mipsisa32r6, etc).
(From OE-Core rev: bdc9e773c240716c2e2a60ca5d4313cfaa6188b1)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: Update checksum for copyright year changes
Update to the latest stable version
(From OE-Core rev: 30d0e8e895813bc422d60bd00076a7f16035feeb)
Signed-off-by: Derek Straka <derek@asterius.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libunistring is one such library which many autotooled packages
mistake to use from build system if its installed on it. This
is specifically toxic when build host arch is same as target arch
since we only see the problem during runtime but thankfully OE
has build time QA which warns about it.
QA Issue: libidn2: The compile log indicates that host include and/or library paths were used.
Using --with-libunistring-prefix nudges the autoconf system for the
component to first look into target sysroot before going on to search
on the build host
(From OE-Core rev: 9a4ea4ff856e2379888ea5cdcc0e761956e1f53b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm-config is a tool on similar veins as pkg-config but provides a lot
more information and packages which use llvm e.g. mesa use this tool to
poke for llvm related informaiton e.g. version, libpath, includepaths
to name a few, this has few challanges in cross build environments where
llvm-config is supposed to be build for buildhost but provide information
about target llvm which is addressed by building native llvm-config along
with target llvm build, but this is frowned upon by OE build system since
it detects that host paths are being used so we have to build it as part
of llvm-native but then it means install paths for llvm and llvm-native
are different and wrong paths get reported when llvm-config is used.
This is solved by providing YOCTO_ALTERNATE_EXE_PATH variable to let
llvm-config use that path instead of self-relative path to report back
Second problem is when building multi-lib packages base_libdir is different
for target packages but native llvm-config does not know about it so
it reports non-multilibbed paths as libdir and packages can not find
llvm in sysroot. This is fixed by adding another environment variable
YOCTO_ALTERNATE_MULTILIB_NAME which can be set from recipes to set
proper multilib path
(From OE-Core rev: 865eb1c1400e60d09c8f413504123fdfc116a71b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Import from meta-oe layer
- This is useful for many packages where CR-LF
needs to be adjusted, many recipes depend on it
e.g. meta-multimedia libebml and so on.
(From OE-Core rev: bd4a02d8d3cfb476a2da0f4616605c92604266c0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If not defined, llvm build system tries to build one
which then confuses the OE QA system since its building
native tool and target packages in same package build
moreover it is not required since we already have it via
llvm-native
Fixes
ERROR: llvm-6.0-r0 do_package_qa: QA Issue: llvm: The compile log indicates that host include and/or library paths were used.
(From OE-Core rev: 7153a17166d9a94fd0ddc36d597a0140979d58ff)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Original approach to add -no-<pie> flags cause link time behavior changes
where packages start to lose the -fPIC -DPIC in compiler cmdline and this
list keeps growing as we build more and more packages,
Instead lets just remove the options we dont need from SECURITY_CFLAGS
this makes it more robust and less intrusive
This also means we do not need to re-add pic options as we started to do
for affected packages
(From OE-Core rev: 1520f5a345fd03d46f33f0efaf76191e96344bec)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Here is the primary driving enhancement:
* Bug 12785 - Support Project Specific configuration for external
tools (e.g. ISS, Eclipse)
- Isolated project-specific configuration page (full Toaster context
hidden)
- Support for new project, reconfigure existing project, and import
existing command line project
- Ability to define variables (e.g. image recipe) and pass them back
to external GUI
- Ability to execute the cloning phase, so that external GUI receive
a buildable project
- Ability to call back to the external GUI when updates are completed
and ready
- Compatibility of above projects with the normal full Toaster interface
- Ability to pass to a 'complete' or 'cancel' web page so that the
external GUI can immediately stop that Toaster instance, and not
leave dangling servers nor edit sessions open
Here are the supporting enhancements, where at least the
back end is implemented:
* Bug 12821 - Make Toaster conf changes compatible with command line usage
* Bug 12822 - Support importing user changes to conf files into Toaster
* Bug 12823 - Support importing user build directories into Toaster
* Bug 12824 - Scan imported layers for content so that they are
immediately available
* Bug 12825 - show layer clone item in progress bar
Here are defects fixed:
* Bug 12817 - builddelete.py requires explicit 'add_arguments'
* Bug 12818 - Remove orphaned imported layers when project is deleted
* Bug 12826 - fix imported layer management
* Bug 12819 - build using selected bitbake env, not Toaster's env
* Bug 12820 - Toaster randomizes the layer order in toaster_bblayers.conf
[YOCTO #12785]
(Bitbake rev: 985d6cec290bdd80998a63483561a73c75d82d65)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existing kernel-devsrc package starts with a full copy of the kernel
source and then starts to strip out elements that are not required.
This results in extra time (I/O) and extra space being taken up in the
final package. The main purpose of the kernel-devsrc package has been to
build modules against the running kernel, not to include a full copy of
the source code for re-building the kernel. The end result was a
600M kernel-devsrc package.
This restructuring of the package uses an approach similar to other
distros, where the kernel-devsrc package is for building against the
running kernel and uses a curated set of copied infrastructure, versus
a mass copy of the entire kernel.
The differences in this approach versus other is largely due to the
architecture support and the split build/source directory of the
kernel.
The result is a kernel-devsrc package of about 10M, which is capable
of running "make scripts" and compiling kernel modules against the
running kernel.
Along with the changes to the copying of the infrascture, we also
have the following changes:
- a better/more explicit listing of dependencies for on-target
builds of "make scripts" or "make modules_prepare"
- The kernel source is installed into /lib/modules/<version>/build
and a symlink created from /usr/src/kernel to the new location.
This aligns with the standard location for module support
code
- There is also a symlink from /lib/modules/<version>/source -> build
to reserve a spot for a new package that is simply the kernel
source. That package is not part of this update.
(From OE-Core rev: 007ef1f468110b2698a27ea9a6d43fed5a0a9fc2)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refresh the following patch:
"disable-graphviz.patch" to fix this warning:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.htmlhttps://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
checking file configure.ac
checking file libvaladoc/Makefile.am
checking file libvaladoc/html/basicdoclet.vala
checking file libvaladoc/html/htmlmarkupwriter.vala
Hunk #1 succeeded at 51 with fuzz 1 (offset 8 lines).
(From OE-Core rev: dfbbff39cfd413510abbd60930232a9c6b35d765)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
