do_kernel_metadata gathers and sanitizes the meta-data that is used
in later steps of the kernel-yocto build process. The processing
takes the form of configuration and patch gathering.
The current single pass of both config and patch gathering means
that patches can't modify in-tree configuration elements (although
this makes tracing configuration changes harder, it is a valid
workflow).
We can divide the routine into a patch and configuration phase, and
call the config variant after patching is done. This keeps the
common parts of the gahering intact, but allows us flexibilty in
when the stages happen.
(From OE-Core rev: 004da4c6c6029bb2bdcea6da8afa70368ddd1bca)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To aid classifying options and streamling reports, fragments
and classification info are consolidated into a kernel meta
directory.
The name of the meta directory is (somewhat) flexible, and hence
is queried by the tools and created if it doesn't exist.
The recent enhancements to the .config auditing introduced a
new query for the meta directory, but isn't being run in the
kernel's source directory .. and is hence creating an unwanted
file in $TOPDIR. We set the kernel source directory as the cwd
for the call, and everything goes back to where it belongs.
(From OE-Core rev: 36f95f5e22cb4858c927f2a5a3bfeae630a41f1d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling xilinx-zynq board linux-kernel-dev(v5.8) if
"GCC_PLUGINS=y", The following error will appear:
"HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o
fatal error: gmp.h: No such file or directory"
the GCC_PLUGINS depend on return result of gcc-plugin.sh execution
however in gcc-plugin.sh use HOSTCC to detect the feature of GNU
extension of gcc, this will result that HOSTCC can compile the file
successfully, but HOSTCXX is used in the actual compilation process.
(From OE-Core rev: 740d87766cb87f75c477666d97cb0480c10217f4)
Signed-off-by: Zhang Qiang <qiang.zhang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake projects can specify the NONE project type. Projects that do this
do not use any C or C++ compiler, this currently works fine with caveat
that when changing the machine/arch the compiler is different causing
signature hash differences.
To avoid the signature hash differences clear the associated C/CXX
compiler variables. In order to achieve this with overrides, simplify
the existing construction of the values using a python function and
variable setting and remove the anonymous variable setup.
(From OE-Core rev: e0657ff13453deedbdcf7c2f8a8854f601c659bd)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently uninative handles SOURCE_MIRROR_URL but not generic PREMIRRORS.
It can handle this better, attempt to iterate PREMIRRORS entries.
(From OE-Core rev: 6426c952b5ade48ea94fb647efc464e603989b97)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildtools is built as a nativesdk which needs to use OECORE_NATIVE_SYSROOT
for its own purposes and can reset it. Save and restore the value
within the eSDK so the two don't clash.
(From OE-Core rev: 513f4006bf563620ee063ba6d0e9b3f27334642e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable the kernel-yocto bbclass to use enhanced capabilities from
the kern-tools symbol_why.pl.
We bump the kern-tools SRCREV to pickup the reworking of symbol_why,
which uses Kconfiglib to provide analysis on configuration values.
This is useful for debugging why a symbol specified in a fragment
did not end up in the final .config.
We introduce two ways to interact with the new symbol_why:
1) a replacement of the existing kconf_check script
2) a dedicated task that is explicitly invoked to dump details
on the configuration.
The kconf_check replacement is transparent to the user, and is
run in exactly the same way as it was previously. But we get better
output and more detailed diagnostics if there are symbols that
don't make it into the final .config
The second way to interact with symbol why is via the new task
do_config_analysis. This is invoked like any other task, and by
default will provide a full configuration analysis and point the
user at files to look at for details.
If a more targetted analysis is desired, then specific symbols
can be set in the CONFIG_ANALYSIS variable. When this variable
is set, the task will only run for the given symbols and provide
per-variable links to the user. This variable can be set like
any other, including specification in the local.conf:
CONFIG_ANALYSIS_pn-linux-yocto-dev = 'NF_CONNTRACK LOCALVERSION'
Which produces output as follows:
WARNING: linux-yocto-dev-5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0
do_config_analysis: Configuration analysis executed, see: tmp/work/qemuarm64-poky-linux/linux-yocto-dev/5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0/NF_CONNTRACK-config-analysis.txt for details
WARNING: linux-yocto-dev-5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0
do_config_analysis: Configuration audit executed, see: tmp/work/qemuarm64-poky-linux/linux-yocto-dev/5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0/NF_CONNTRACK-config-audit.txt for details
WARNING: linux-yocto-dev-5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0
do_config_analysis: Configuration analysis executed, see: tmp/work/qemuarm64-poky-linux/linux-yocto-dev/5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0/LOCALVERSION-config-analysis.txt for details
WARNING: linux-yocto-dev-5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0
do_config_analysis: Configuration audit executed, see: work/qemuarm64-poky-linux/linux-yocto-dev/5.8-rc++gitAUTOINC+d22beb8f8a_8fc484ed37-r0/LOCALVERSION-config-audit.txt for details
(From OE-Core rev: cbc896def4c8bab3150d3405969e5dd018d62d0c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce the KCONFIG_CONFIG_ROOTDIR variable to allow recipes
which the .config file is not under the ${B} to select the root
directory location for the config file.
(From OE-Core rev: f86282ad2c66f843e000a889c403b3f09bce33f0)
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds support for adding configuration node even
when dtb is not part of the FIT image. The conf and default
node number are therefore changed to point to kernel ID rather
than dtb ID when dtb does not exist.
(From OE-Core rev: 2d9f3c3d763e2bca704da4019add973b9a2c572f)
Signed-off-by: Usama Arif <usama.arif@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a build-time race condition that resulted in intermittent build
failures in the do_assemble_fitimage task. The race condition involved
the do_assemble_fitimage task reading the vmlinux file while the
do_compile_kernelmodules task was re-writing the vmlinux file.
This can be seen with an aarch64 image build that uses a 5.4 based
kernel and sets KERNEL_DEVICETREE. The problem is that the do_compile
snippet that the kernel-devicetree class appends did not specify the
full kernel build environment when building the DTB(s) from the kernel
tree. This resulted in CONFIG_CC_CAN_LINK=y being removed from the
kernel config file just before the do_compile task completed. The
CONFIG_CC_CAN_LINK=y line was then re-inserted into the kernel config
file as part of the do_compile_kernelmodules task.
In some cases, this resulted in the do_compile_kernelmodules task to
re-link vmlinux which sometimes occured at the same time that the
do_assemble_fitimage task was attempting to use vmlinux. The
do_assemble_fitimage task would fail with the following error message:
aarch64-poky-linux-objcopy:vmlinux: file format not recognized
We can use the pine-a64-lts machine, from the meta-pine64 layer, to show
that the kernel config file was changed between do_compile and
do_compile_kernelmodules:
$ C=tmp/work/pine_a64_lts-poky-linux/linux-pine64/5.7+gitAUTOINC+ae03bade3b-r0/linux-pine_a64_lts-standard-build/.config
$ bitbake -c do_kernel_configcheck virtual/kernel
...
$ md5sum $C; grep CC_CAN_LINK $C
32b133cf8a749a91f698a7ca8616c84f ...
CONFIG_CC_CAN_LINK=y
$ bitbake -c do_compile virtual/kernel
...
$ md5sum $C; grep CC_CAN_LINK $C
2fd2ec2a66eecc329dcb5afaf005eada ...
$ bitbake -c do_compile_kernelmodules virtual/kernel
...
$ md5sum $C; grep CC_CAN_LINK $C
32b133cf8a749a91f698a7ca8616c84f ...
CONFIG_CC_CAN_LINK=y
With this change, the do_compile snippet appended by the
kernel-devicetree class does not modify the kernel config. The kernel
config is unchanged across the do_compile and do_compile_kernelmodules
tasks and do_compile_kernelmodules will not attempt to re-link vmlinux.
(From OE-Core rev: 74619de0277471f446bf7a719f4c445359c823f6)
Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_FEATURES are explicitly checked by the kern-tools, and trigger
and error when not present. This is since the KERNEL_FEATURES are
specified by layers or BSPs as elements that are requied for correct
operation.
That being said, in order to support more kernel recipes that are using
fragments, but not necessarily the yocto kernel-cache for meta-data,
this change introduces: KERNEL_DANGLING_FEATURES_WARN_ONLY
As you'd expect, when set, missing kernel features only print a
message and warn that runtime issues may occur, but otherwise allow
the kernel configuration and build process to continue.
This was noticed/required when meta-virtualization adopted a more
generic kernel bbappend (to serve the needs of more layers in the
ecosystem), but also specifies some KERNEL_FEATURES. If layers using
a recipe derived from kernel-yocto, but not the main kernel-cache,
used meta-virtualization and error would be thrown due to missing
features. We now can both allow them to continue, and also provide
a more useful message to resolve the issue.
(From OE-Core rev: 8d44ea9fbb1ee7bec1062505a9bb1e2d7b360094)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is required by newer meson versions in cross builds, as
acknowledgement that the tool in PATH is ok to use.
(From OE-Core rev: 267d1dc0794fc348a5f7af3de201c452c8b705a3)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'bitbake world -k' when DISTRO_FEATURES don't have x11 and wayland,
report errors:
Nothing PROVIDES 'gtk+3'
Nothing RPROVIDES 'blueman'
gtk+3 set ANY_OF_DISTRO_FEATURES, so add it here too
since we DEPENDS on it
(From OE-Core rev: ab9ff563c77cd5105f4ef9426f076b10ea8e2ee8)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
remove the traling blanks before the ;-delimiter, so one could use
"_remove" to avoid running tasks like 'rootfs_update_timestamp',
which are currently hardcoded and not bound to any
configurable feature flag
(From OE-Core rev: 8c835f63c2bca0a66385eb7ea5ec021d86265777)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildhistory create .txt file bh_installed_pkgs.txt and
bh_installed_pkgs_deps.txt while listing down installed package.
These file is later removed in buildhistory_get_installed().
when multiple process runs in parellal there are chances to race for
the file where one process created the file while another task remove
the file right after it.
using different file name for each process should avoid the race. So
add PID to the file name to make it unique.
[yocto #13709]
(From OE-Core rev: 214d236d93700abffa2d586cc744a00455818fa4)
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
package libgtk-3.0 don't install dir /usr/lib/gtk-3.0/3.0.0/ by default.
when install package gtk-immodule-xim, it is possible met below error:
/var/tmp/rpm-tmp.tlfoeo: line 17: /usr/lib/gtk-3.0/3.0.0/immodules.cache: No such file or directory
warning: %post(gtk-immodule-xim-2.24.32-r0.0.cortexa72) scriptlet failed, exit status 1
fix by create the dir when try to write to /usr/lib/gtk-3.0/3.0.0/immodules.cache
(From OE-Core rev: c689e120961d9d20386c8b822d71d778d4e6df7b)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code was using TARGET_OS to try and detect what type of OS the
packages would be running on, but this is incorrect. TARGET_OS is the OS
for which the package will generate output (e.g. GCC output target or
GDB debugging target). The OS where the package will run is the HOST_OS.
Note that HOST_OS only differs from TARGET_OS when doing a
canadian cross compile, and even then in our case only when doing so for
a non-Linux host (e.g. MinGW).
Fix the code to use HOST_OS instead.
(From OE-Core rev: f284c5b2df220b520b025a59874e04ef4becd829)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the class to use HOST_OS and HOST_ARCH to set the cmake SYSTEM
variables. The HOST variables should be used instead of
TARGET_OS/TARGET_ARCH because we want to control how cmake compiles for
where the package is going to run (the host), not what it will be
generating output for (the target). The distinction is only really
relevant when building canadian cross recipes.
Also fix up the host OS detection to account for MinGW by setting
CMAKE_SYSTEM_NAME to "Windows". This eliminates the need for meta-mingw
to patch this in all the cmake recipes it builds.
(From OE-Core rev: 01245db2893e39ffb5d4a00e4689f048d0698974)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves most of the python code used for dealing with the source date
epoch to library code.
(From OE-Core rev: a7ede90955bc0c8bec1cbb3cab498ef2583b2f4e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test for whether or not scc should to invoked to generate a
config.queue was missing the newly created sccs_defconfig variable.
We need to test for that variable as well, or we may miss generating
the config.queue in some cases.
(From OE-Core rev: 3a95e171d3eaa6ab143d4f422c98a0ac7ad31761)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The messages from the ELF 'arch' test are not obvious, clarify the
messages and prune output paths.
(From OE-Core rev: 8211b42f10b0f2a8e415fee680b37b5ce224a2d5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
help2man-native doesn't need to be handled specially, we can build it
normally or use INHIBIT_AUTOTOOLS_DEPS like everyone else.
(From OE-Core rev: 886e7d08208c8788488f8299786140fd5b61e548)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cve-check file should be saved always, it has good info.
Put a copy in the log dir as cve-summary with symlinks to latest run.
[Yocto #13974]
(From OE-Core rev: 859849c7b594d844819ad8c3f7d8325388d94b93)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Further to 96c20c9df7:
Try to avoid nativesdk recipes accidentally being dependent on MACHINE_FEATURES.
(From OE-Core rev: 956e5bd6862ca898143a234aa85cc83b1f2d1807)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot.inc and busybox.inc contain identical copies of this little
helper. They both inherit the cml1 class and use cml1_do_configure
right after having used this helper, and other recipes that want to
write similar logic for doing Kconfig via fragments will also need it
or something equivalent.
(From OE-Core rev: af687c9137a3e8efe48afa6fd12866cf656ae913)
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
as ptest FILES could be determined before or after the classes was
inherited, if is much safer to append to the setting of
FILES_${PN}-ptest
(From OE-Core rev: 419ad35ffe7f5199e49a246ef9854f0810ca1d6c)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the course of do_package_rpm and friends the tools create a
top-level CONTROL or DEBIAN directory in the package directory.
do_package_qa needs to be aware of these files and ignore them, this was
previously done in just one check but instead should be done once when
building the file list so all the checks don't see the temporary files.
[ YOCTO #13804 ]
(From OE-Core rev: 4b2f45c47a5c8c800626f12c14f216a5ab923512)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The project is a strong supporter of SPDX but this class is old code using
a dated approach which now misleads people. Remove it.
The meta-sdpxscanner layer is a much more modern and active approach to
handling this and we should be pointing people there.
(From OE-Core rev: 871599bf76b3fb635efd416340803f7bf3341f7e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
a native lzop is only needed when an lzo compressed initramfs is actually present
(From OE-Core rev: 1217ddf070261c5fe523729b2a833bd38f1e4ccd)
Signed-off-by: Timon Ulrich <t.ulrich@anapur.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Baremetal applications or an RTOS built with OpenEmbedded can share the same
code to be built as an image, tested and packaged in case they can be updated
as a firmware blob from Linux.
This class creates the proper wiring to mimic OE Linux image creation and
testing infrastructure, inheriting it makes the process of creating a baremetal
application transparent to the developer deploying it automatically along with
its required bits to be run and tested.
(From OE-Core rev: 34df656e1d7070337f62c8fd9b2dc27491275416)
Signed-off-by: Alejandro Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a modules tarball is created during kernel_do_deploy,
the tarball is compressed using gzip, but gzip-native is not
a dependency so the build host's gzip is being used for this.
Using gzip-native will, by default, use pigz instead of
single-threaded gzip, making this task less of a bottleneck
for builds with a large modules package.
(From OE-Core rev: 1243aad78601e9a5c0a3471c8a105c429536599d)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fetcher provides full paths to defconfig and scc files, which awk
comparison operator does not catch during construction of
src_uri_defconfig and sccs_from_src_uri lists. This causes the
src_uri_defconfig variable to come out empty, and fails further
validation if defconfig is only supplied via SRC_URI.
Replace comparison operator with awk match function which searches for
sub-string during filtering, effectively placing defconfig from SRC_URI
into src_uri_defconfig and scc files in sccs_from_src_uri respectively.
Fixes: 23dcff0d39 (kernel/yocto: ensure that defconfigs are processed first)
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
(From OE-Core rev: f52ce0fa98bf3bd72df7467031001f3128c145f2)
Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: bb946b8cdbd01408bfa0ba8e53f9e09931dfb29d)
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the initramfs image is type lz4, then a native lz4 is needed.
Additionally an output filename needs to be specified when calling lz4,
otherwise STDOUT will be used implicitly.
(From OE-Core rev: c83a7aec59defbbc049d44ba34a7a409ada4fa19)
Signed-off-by: Timon Ulrich <t.ulrich@anapur.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit d4be264061 ("classes/archiver: run do_unpack_and_patch after
do_preconfigure") correctly moved do_unpack_and_patch to depend on
do_preconfigure, but left do_ar_patched as a dependency of do_configure
introduced from 8a7c779487 ("classes/archiver: Create patched archive
before configuring"). Having do_configure depend on do_ar_patched is
blatantly wrong. Firstly, doing so causes the taskhash of do_configure
to change which is undesirable. Secondly, the anon python that sets up
the tasks carefully skips GCC recipes that depend on gcc-source to
provide their source code since running do_unpack_and_patch in them
would delete the source code. Adding in the dependency effectively
bypasses this and makes these recipes delete the shared gcc-source
This fixes errors (for real this time) like:
cat: .../gcc/defaults.h: No such file or directory
when making certain configuration changes.
For posterity, you could easily reproduce gcc-source being erased by
running the commands (replacing aarch64 with your correct target arch):
bitbake -c cleanall gcc-source gcc-cross-aarch64
bitbake -c do_deploy_archives gcc-source
# The following would fail because
# gcc-cross-aarch64:do_unpack_and_patch erases shared source, so
# do_configure after that fails.
bitbake gcc-cross-aarch64
(From OE-Core rev: f02c1904330da47a25cf85f0077712f584f4ee5b)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if the find command finds /home it stops checking the other
files. Tweak the find expression to fix this.
Also, from Alex Kiernan <alex.kiernan@gmail.com>, generate output for
each contaminated path so it's visible in the main log file.
When matches are found, dump the data from the group and passwd files
so useful debugging can be done based on the results.
(From OE-Core rev: 504f1d158bf7c6ad08fbce755021db2b14565231)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
fix error:
+ /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache
/var/tmp/rpm-tmp.mdYxY6: line 12: /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: No such file or directory
%post(adwaita-icon-theme-3.36.1-r0.0.noarch): waitpid(2961) rc 2961 status 7f00
warning: %post(adwaita-icon-theme-3.36.1-r0.0.noarch) scriptlet failed, exit status 127
when install adwaita-icon-theme on target, which inherit gtk-icon-cache
above error reported, fix by add runtime dependency to pkgs
we don't use explicit RDEPENDS, so fix do_rootfs breaking by adding it into DEPENDS.
Error:
Problem: conflicting requests
- nothing provides gdk-pixbuf needed by adwaita-icon-theme-3.36.1-r0.noarch
- nothing provides gtk+3 needed by adwaita-icon-theme-3.36.1-r0.noarch
(From OE-Core rev: 31e3d34c8a9c3e8481aa837aa0bf52adf095fe62)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit 8a7c779487 ("classes/archiver: Create patched archive before
configuring") fixed a race condition when using the archiver, but
introduced a bug where the GCC source would occasionally be deleted due
to the archiving code running before do_preconfigure. Instead, make sure
the archiving code runs after do_preconfigure by making
do_unpack_and_patch depend on it. This makes more sense anyway since
do_preconfigure is effectively an extension of do_patch.
This fixes errors like:
cat: .../gcc/defaults.h: No such file or directory
when making certain configuration changes
(From OE-Core rev: d4be264061023ae0ea6e023d82a7b99605bfc22c)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_deploy should clean up ${DEPLOYDIR} before running, just like do_install
cleans up ${D} before running. This reduces the risk of DEPLOYDIR being
accidentally contaminated by files from previous runs, possibly even with
different config, in case of incremental builds.
It is convenient to have this in deploy.bbclass, so it doesn't have to be
duplicated in every recipe, considering for example meta-freescale, which
has 23 affected recipes.
All recipes using deploy.bbclass (grep -r 'inherit .*deploy') in poky,
meta-openembedded and meta-freescale look like they either benefit from
this or are at least not affected negatively by it. The only exception
I've noticed was uboot-sign.bbclass, which was however fixed by the
previous patch.
(From OE-Core rev: 7083a7d56f4d90c81d2e6652ee291d20fd908bbe)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When inherited by the u-boot recipe (UBOOT_PN), uboot-sign.bbclass adds
a concat_dtb step, which places additional files into ${DEPLOYDIR}
before do_deploy. By turning this from a prefunc into a part of the normal
do_deploy function, it becomes possible to use
do_deploy[cleandirs] = "${DEPLOYDIR}"
in the future, without deleting the files produced by concat_dtb.
As before, care is taken to not interfere with the kernel's do_deploy
definition, since concat_dtb was only needed for u-boot.
(From OE-Core rev: 17619c1a41fa961afc317e4aafab9cdc4ff14a49)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is uncommon that a BSP definition and a defconfig are used in
a single configuration. That being said, it is a valid way to
organize kernel configuration meta data.
When a defconfig is used, either on the src_uri or from in
the kernel tree, it is normally expected that it is the baseline,
with all options applied on top of it.
With this commit, we detect either type of defconfig and ensure
that it is used first, followed by the fragments in their
previous order. This allows existing configuration stacks to
remain the same, while ensuring that a defconfig combined stack
works as expected.
(From OE-Core rev: e6845327b69396d843a2f3c4c3ac9400ae9caedf)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should be using python3 here, it was missed in the conversion. Spotted on
autobuilder tests failing on systems with python missing.
(From OE-Core rev: db07b09196022078346aadd565760240b7da6a71)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Starting from v5.8-rc1 commit 269a535ca931 (modpost: generate
vmlinux.symvers and reuse it for the second modpost"), kernel will
generate new vmlinux.symvers instead of dumping all the vmlinux symbols
into Module.symvers in the first pass.
Error log:
'run.do_shared_workdir.16614' failed with exit code 1:
DEBUG: cp: cannot stat 'Module.symvers': No such file or directory
This change will check the file Module.symvers existence before copying it.
(From OE-Core rev: cd2d62a08a1dfcd890a03ee55132b6d6c65f5ab7)
Signed-off-by: Lili Li <lili.li@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
fix error during post uninstall:
%postun(shared-mime-info-data-2.0-r0.4.corei7_64): execv(/bin/sh) pid 78
+ '[' 0 = 0 ']'
+ set -e
+ '[' x '!=' x ']'
+ echo 'Updating MIME database... this may take a while.'
Updating MIME database... this may take a while.
+ update-mime-database /usr/share/mime
Directory '/usr/share/mime/packages' does not exist!
%postun(shared-mime-info-data-2.0-r0.4.corei7_64): waitpid(78) rc 78 status 100
warning: %postun(shared-mime-info-data-2.0-r0.4.corei7_64) scriptlet failed, exit status 1
when run post uninstall scriptlet, /usr/share/mime/packages has been
removed during unintall, while update-mime-database will check xml under
/usr/share/mime/packages.
workaround by create this dir before update, then remove it
(From OE-Core rev: 6f262a316d6c32ff9ce96ab4bd95726772b5f20f)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Major update after v4.2.
Changes:
- os_find_datadir() was changed after the v4.2 release
causing v5.0 to not find the bios and not boot the
image. Fix is sent to upstream qemu.
See: qemu/find_datadir.patch
- v5.0 binary had host contamination for dynamically linked
libraries, "--extra-ldflags='${LDFLAGS}'" in EXTRA_OECONF
resolved the issue
- bluetooth code was removed: qemu.git$ git show 1d4ffe8dc7
hence removed PACKAGECONFIG[bluez]
- -show-cursor qemu option is now deprecated, updated
scripts/runqemu to use updated option instead
- added PACKAGECONFIG definitions
- added qemu-ptest to conf/distro/include/ptest-packagelists.inc
- increased support for ARM architecture, cpu and board
- removed patches merged upstream and refreshed
existing ones
Testing:
Build core-image-minimal against the machines in
openembedded-core/meta/conf/machine and succesfully
booted with qemu v5.0
Ran qemu-ptest on x86-64 and arm64 with identical results:
PASS: 1166
SKIP: 0
FAIL: 0
(From OE-Core rev: ee9ec9e344541c1ccd9b9b8e3b8c1e00d008ad85)
Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_configure and do_preconfigure can modify source files, which causes
race conditions if these tasks run in parallel with do_ar_patched. Add
explicit task dependencies to ensure that do_ar_patched finishes before
these tasks start. Specifically, this fixes a race condition with
gcc-source where do_ar_patched races with do_preconfigure deleting
gcc/gengtype-lex.c
(From OE-Core rev: 8a7c7794870815030239e90b03e37ed302b7e885)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to sign_ipk, ignore the number of threads used for signing
RPMs.
(From OE-Core rev: 77be5fd7df96ebd5a07bfaa3921c074ef8c470c7)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
