Made sure that the terms "OpenEmbedded-Core" and "OE-Core"
are used as such throughout the manual.
(Bitbake rev: 677e58f8616a4bf58772e54d2313af3885a3b110)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-firmware contains ${PN}-license package since this commit:
commit 1ee083da0730408fffdbbf5f29abc299c0e61be9
Author: Jackie Huang <jackie.huang@windriver.com>
Date: Mon Apr 13 10:17:21 2015 +0800
linux-firmware: fix the mess of licenses
* LICENSE_CREATE_PACKAGE functionality in license.bbclass when enabled
adds new package with suffix:
LICENSE_PACKAGE_SUFFIX ??= "-lic"
but then it checks if ${PN}-${LICENSE_PACKAGE_SUFFIX} is included
in PACKAGES before adding it and when found it shows:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: linux-firmware-lic package already existed in linux-firmware.
and doesn't add the ${PN}-lic to PACKAGES and causes another warning:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: QA Issue: linux-firmware: Files/directories were installed but not shipped in any package:
/usr
/usr/share
/usr/share/licenses
/usr/share/licenses/linux-firmware
that's because it was searching ${PN}-lic in PACKAGES as a string
so it found ${PN}-lic as a substring of ${PN}-license, add a split
to search in an list
(From OE-Core rev: 9b9897fc034819385a9d4ce591cc79dd458f3f24)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* add it to allow older distributions e.g. Ubuntu 14.04 with gcc 4.8
to build this, otherwise it fails with:
../git/gen-des-tables.c: In function 'write_table_u8':
../git/gen-des-tables.c:307:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < m; i++)
^
(From OE-Core rev: 2591741896a6a267ceca9519f21bd39b5b196559)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add option for dbus in configure.ac, and explicitly build without dbus
for rpm-native.
Previously, the rpm recipe tries to prevent rpm-native from attempting
to inhibit shutdown via session dbus by appending '--disable-plugins'
to EXTRA_OECONF in case of native.
However, some layer may need some functionality via plugin support. And
when it enables it, we would meet the following warning at rootfs time.
Unable to get systemd shutdown inhibition lock: Socket name too long
As plugins/systemd_inhibit.c is the only place that's related to this
dependency, we can be sure that dbus is really not needed for rpm-native.
(From OE-Core rev: 815ccef2d5bef1e46c51916e694d0974aee394a9)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since ${SSTATE_ARCHS} now contains ${PACKAGE_EXTRA_ARCHS} there is no
longer any need to add those extra architectures to the list of
architectures handled in get_deployed_dependencies().
(From OE-Core rev: e55e6df4f1434458cdfa0e2d3610b48119e5a782)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes sure files provided by packages that use any of the extra
architectures defined using ${PACKAGE_EXTRA_ARCHS} are cleaned from
tmp/sysroot-components when sstate_eventhandler2() executes.
Without this, changing a package from using one of the extra
architectures to another architecture would lead to files being
leftover in tmp/sysroot-components, which could later be picked up
when creating the RSS for another package rather than the files that
belonged to the updated package.
(From OE-Core rev: b959b3bd92aa2939d407800fc4167b0535fd4674)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this change, there will be two sstate index files in
tmp/sstate-control for any machine that contains a dash in the
name.
(From OE-Core rev: 29e7799bdb3773c40492e01448e0c614ed44583d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc
despite the change not having merged into glibc upstream yet. This breaks the use of
uninative in OE on fedora28 since binaries there are now using new symbols only found
in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the
reverse.
Since this will impact OE in the next release cycle, this changes nativesdk only
to use this new model and adds libxcrypt to work in that case. This allows us to
build a uninative which is compatible with fedora28 and previous other OSes.
In order to work, recipes will now need to depend on virtual/crypt where they use
libcrypt since its now a separate library and we can't depend on it from glibc to
preseve backwards compatibility since glibc needs to build first. For now, only the
problematic nativesdk recipes have been fixed up. For target use, the default
provider remains glibc for now. Assuming this change is merged into upstream glibc,
we will need to roll this change out for the target but we will do this in the next
release cycle when we can better deal with the resulting bugs.
[1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Original patch from Charles-Antoine Couret <charles-antoine.couret@essensium.com>,
tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor
tweaks.
(From OE-Core rev: c1573cb7faeb296fe7077a60d02443d5ed5bded0)
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated
code from devtool needs to set this to avoid warnings which break
various tests.
(From OE-Core rev: f65ebfeda0bfbac78e4a2a6609ba654ca38a8b0e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated
code from devtool/oeqa needs to set this to avoid warnings which break
various tests.
(From OE-Core rev: 27568410ebb0d40db3428550704f35199df0e034)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alejandro asked this be reverted as the patch causes more problems
than it solves.
This reverts commit 5d288d286e.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add Perl's patch submitted to upstream to be compiled along with glibc with libcrypt split.
(From OE-Core rev: 79703d83790a2973fefdb0e12e125b5f17e98cdf)
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the package will get an automatic prefix "kernel-module", so
the package kernel-module-hello does exist, populating rootfs can
generate an error:
- nothing provides kernel-module-hello ...
This is quite unfortunate, as this recipe is used as a sample.
Adding RPROVIDES_${PN} += "kernel-module-hello" to the recipe fixes
the problem.
[YOCTO #12641]
(From OE-Core rev: ca17a7bbea5f5454da43545d544ff7772d83ac19)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New crosstap python implementation is total replacement for
crosstap shell script, that has superseding capabilities.
New script support cross compiling of SystemTap scripts
for user-land, by using supplied image rootfs. Whereas old
script could only deal with scripts against kernel. New script
has more complex logic and additional capabilities.
As invocation interface new script support old "legacy"
mode and provides alternative new regular options interface
to access additional functionality.
(From OE-Core rev: 1cbbcf26e0a9ca6e0b34a89512bf75dbae8bfaf0)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For details on issues fixed please look at commit message of individual
patches.
Upstream-Status: Backport [systemtap@sourceware.org]
(From OE-Core rev: 5aa93de3a79c8691e74e982d3d4b0099b04f5555)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For cases when systemap module compilation happens on host in
cross-compilation mode, and it is desirable to minimize systemtap
presense on target we need to have just smallest possible set of
utilties that are required to run compiled modules.
Introduce new "translator" PACKAGECONFIG, if it is not set
it would mean that just minimal set of run-time utilities will
be included in the package.
For run-time only systemtap build variant use
PACKAGECONFIG_pn-systemtap = "" or
PACKAGECONFIG_pn-systemtap = "monitor"
Suggested-by: Taras Kondratiuk <takondra@cisco.com>
(From OE-Core rev: a22b8140c6924eb3b3cd7b5bea66a4d3ed413807)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is IMAGE_GEN_DEBUGFS="1" variable that enables build of
additional rootfs-dbg and additional archive that contains
complimentary symbols files for a given image. But the issue
with this resulting directory and tarball that before use it
has to be combined with original image content. It is required
since all cross debugging tools like gdb, perf, and systemtap
need file system that contains both target executables/libraries
and their symbols. Those tools need to find executable/library
first and through it debuglink note find corresponding symbols
file.
image-combined-dbg when added to USER_CLASSES just copies
final resulting rootfs back into rootfs-dbg creating combined
target and debug symbols rootfs that can be used for debugging
directly.
(From OE-Core rev: 7ccb077f51c9232de70e5c6f9897fd9986e3be9d)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since v7.51.0, libidn2 is the only available option, libidn
support was dropped.
The configure option was renamed as of v7.53.0
Therefore, curl unconditionally tries to build against libidn2,
which in particular is a problem for curl-native, as that might
or might not build against the build-machine's libidn2 now,
which furthermore causes problems when trying to share sstate
between multiple build machines.
We therefore see the following in the config log:
...
checking whether to build with libidn2... (assumed) yes
...
checking for libidn2 options with pkg-config... no
configure: IDN_LIBS: "-lidn2"
configure: IDN_LDFLAGS: ""
configure: IDN_CPPFLAGS: ""
configure: IDN_DIR: ""
checking if idn2_lookup_ul can be linked... yes
checking idn2.h usability... yes
checking idn2.h presence... yes
checking for idn2.h... yes
...
IDN support: enabled (libidn2)
...
even though this recipe tries to disable that.
While libidn2 isn't available in OE, this change at least:
* prevents curl-native to silently build against libidn2 if
that is installed on build machine, even if not requested
* alerts people who use the PACKAGECONFIG option that it's
not actually doing what they intend to do
(From OE-Core rev: 705eaea991622bdbb2ee83eefa8df8e665e3efe4)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 has been supported since GCC 5.1, sparc has been supported
since 4.9, and S390 since 7.1.
(From OE-Core rev: a2cbb5dc4c6191ca343dc4211abde693dc1a579a)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 has been supported since GCC 5.1, sparc has been supported
since 4.9, and S390 since 7.1.
Also mark as broken entirely with musl.
(From OE-Core rev: 7d90d2a70f0184ad715e9917d3e7aa096cf98f79)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We'd like layers to set this variable so that we know which layers are compatible
with which others, even if the branch is a generic un-updated "master" branch.
Start printing a warning to highlight this issue.
(Bitbake rev: cca81e33b58c390dcf5cc3a31555a43b79177166)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also set LAYERSERIES_COMPAT for core (we're compatible with ourself).
(From OE-Core rev: 4aa43cd844781a07a2dbf17f21ed35c6a0100d02)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adpat to the upgrade from 5.0 -> 6.0.
(From OE-Core rev: dc52f9cf343df4c2d77bee0e47004466321e7edb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: bae5ced6eba78f1903e15d7f9dd7afc3c06e8955)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools,
there is no need to repeat it here.
(From OE-Core rev: 9a514311fa062fa3f8bccc4c47e907f88221024a)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: 301d153781c7ddb6e38178c56f960e18d62788ab)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: 2eb7ba6cb68e171c880bcb1fc614f1ae6b300e4f)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PRINC is no longer used and removed from documentation:
commit 7baadd86ee
Author: Scott Rifenbark <scott.m.rifenbark@intel.com>
Date: Mon May 18 09:25:51 2015 -0600
ref-manual: Removed PRINC entry from the glossary
(From OE-Core rev: b15089b014b95a8730f622ca4959b42ed15cb175)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When archiving a kernel, if S is ${WORKDIR}/git, then
${WORKDIR}/git is in fact a soft link into work-shared,
and the archive contains just the soft link. Fix by
archiving the real directory.
(From OE-Core rev: 564204dd6b73697ef4b6c17243067892876cc323)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Special handling for kernel source in work-shared was
incorrectly limited to kernel-yocto.bbclass instead
of kernel.bbclass.
(From OE-Core rev: b8c5680a67888d43540366a40bd0c501e926ac31)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have postinst intercept execution working for SDK generation,
adding MLPREFIX again makes sense in all cases, as the intercepts do require
that it is there.
This reverts commit 4ffb728df4.
(From OE-Core rev: 0792540170b6150a0c5fe8586bb8012affc3f90e)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When it was something else than /usr/libexec (e.g. when
installing native SDK packages), things broke down.
(From OE-Core rev: d99e819a6cbde6d1116c434ddba4c5f8eca7e6d8)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously this wasn't done, and so any packages installed from
populate_sdk would not have the postinsts fully executed
(particularly generation of various caches via running nativesdk or target
binaries with qemu wasn't working).
[YOCTO #12630]
(From OE-Core rev: a484ff072eea3f47de2c3348048201249cefa46b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows running the intercepts when creating SDKs, which previously
wasn't possible, as SDK code does not use the rootfs class, and calls
into PackageManager methods directly.
(From OE-Core rev: f830388c5e9125f385a42acd7365d1235967b57c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow handling postinst_intercepts when populating SDKs (which
use PackageManager class directly, and do not utilize RootFS class).
(From OE-Core rev: 9454fd328040fd58c981d028a74fcf181bde8e89)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will be useful when also moving postinst_intercept handling to
package manager class from rootfs class.
(From OE-Core rev: a4cd69bdd5b9dfa1125887f4d9038d41996e39c7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its use required a script from an external repo which hasn't been updated
in 4 years, the recipe itself is out of date (doesn't install all
intercepts), and there is no oe-selftest or documentation for this.
If anyone still wants this, please do it in a separate layer.
(From OE-Core rev: 1fbae102fde54c9e7a0d74a4cda9900cd17640d6)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The list of patches in SRC_URI was restructured in 49aae1d7, and left
a comment about patches from Debian hanging without context. Move and
reword it to make it remain useful.
There was also a leftover comment that referred to two .h files and
do_configure_prepend() that were removed in f960c026.
(From OE-Core rev: 80a702db442674e16a450a120972eeee4cbcb29a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, RPM_SIGN_PACKAGES is not defined. Add gpgcheck=0 to
oe-remote-repo.repo file, otherwise dnf will complain during
install operation on target
Note, RPM_SIGN_PACKAGES is set only when you inherit sign_rpm explicitly
(From OE-Core rev: 002a71eaa7606828c399972d8fd35e19e7b71929)
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This version has been published at April 03, 2018, and it is a bugfix
only release.
The release includes several important fixes that were made as part of
18.0.1 development cycle. Full list of bug fixes can be see online at:
https://www.mesa3d.org/relnotes/17.3.8.html
(From OE-Core rev: 782fb864349d4f5c07a38f0e117659bfb841d3c2)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As introduced by a56fb90dc3 ('base.bbclass
wipe ${S} before unpacking source') the base.bbclass uses a python
anonymous function to set the 'do_unpack' varflag 'cleandirs' to either
'${S}' or '${S}/patches' depending on equality of '${S}' and '${WORKDIR}'.
Not that this only differs from the way almost all other recipes set or
modify a tasks 'cleandirs' flag, it also has a significant impact on the
kernel.bbclass (and possibly further ones) and causes incorrect
behavior for rebuilds triggered by source modification, e.g. by a change
of the defconfig file for a kernel build.
The kernel.bbclass tries to extend do_unpack[cleandirs]:
| do_unpack[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} ${STAGING_KERNEL_BUILDDIR}"
As python anonymous functions are evaluated at the very end of recipe
parsing, the d.setVarFlag('do_unpack', 'cleandirs', '${S}') statement in
base.bbclass will overwrite every modification to cleandirs that is done
as shown for the kernel class above.
As a result of this, a change to a kernels 'defconfig' will lead to an
updated defconfig file in ${WORKDIR}, but as ${B} never gets cleaned and
${B}/.config still exists, it will not be copied to ${B}/.config and
thus not find its way in the build kernel.
This is a severe issue for the kernel development and build process!
This patch changes setting of the cleandirs varflag in base.bbclass to
a simple variable assignment as almost all other recipes do it. This now
again allows overwriting or appending the varflag with common methods
such as done in kernel.bbclass.
This issue affects morty, pyro, rocko and master.
(From OE-Core rev: 20901b9783220aa6e7adae4951c531919c20859b)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that a trailing or extra slash somewhere in the external
source path could result in the directory not being removed from
cleandirs; it's also possible that a cleandirs entry is somewhere
underneath the source tree and that tree should never have parts of it
deleted by the build system. Use oe.path.is_path_parent() (which makes
paths absolute before checking them) to find out if any path in
cleandirs is anywhere underneath the external source path, and drop it
if it is.
(From OE-Core rev: 87ec0fb470274d980f8553a85f778809c269c5d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the existing oe.recipeutils.split_var_value() function to split the
unexpanded value of the cleandirs varflag, in case it contains python
expressions - we don't want to split the expression itself as the chunks
will not expand properly individually and we can miss something that
expands to the source tree (and thus it can get deleted, the avoidance
of which is the whole point of this code).
(From OE-Core rev: 611cee69d7300a4746edd752c9557af60e7beecc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix typo in sulogin-path setting. It should be ${base_sbindir} instead of
just {base_sbindir}.
(From OE-Core rev: c168f6fe35ada66f7d6d6b5151fa248230c38676)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When uninative is activated (poky's default) internal datastore variables are modified (NATIVELSBSTRING and SSTATEPOSTUNPACKFUNCS) to enable uninative
support. This is happening after parsing is done at the beginning of the build. On the next bitbake call the recipe would be parsed if the two
variables above were not added to the parsing whitelist BB_HASHCONFIG_WHITELIST.
The fix is to add these two variables to the recipe parsing whitelist BB_HASHCONFIG_WHITELIST, this is done at recipe parsing time, only when
uninative.bbclass is used.
(From OE-Core rev: 75bb95ada98ef129d2fa48568f27dddb078c852c)
Signed-off-by: Cuero Bugot <cbugot@sierrawireless.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
