The RequiresMountsFor configuration option of systemd.unit (added in
systemd version 201) not only adds the Requires and After options for
the required mount unit, but it adds them for all mount units required
to access the specified path.
So this change is both a simplification, and an improvement.
Not only will all needed mount units be added to Requires and After, but
the overlay path does not have to be a mountpoint, but can be at any
directory level beneath a mountpoint.
(From OE-Core rev: fa2422232a143b21aeea3728abca82100946dbc4)
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Normally flex-native in the sysroot via the toolchain, but different
toolchains may not depend on flex-native (eg, external-arm-toolchain).
This results in a configure error:
checking for flex... no
configure: error: flex is required when building from revision control
Now we're not building from revision control, but the configure script
is broken with out-of-tree builds and checks the (empty) build tree for
pre-generated sources. Apply a fix to look in the source tree instead.
(From OE-Core rev: 544d8ee19b5ac74a841722a3e000019d2e6ab4f8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
When using the -fsanitize=address CXX_FLAG for a program compiled for
aarch64 / arm64
This is happing:
MemorySanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg))
== ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))"
(0xe00000000000, 0xfffffffffffffff4) (tid=51745)
With -DSANITIZER_CAN_USE_ALLOCATOR64=0 this is not happening and
potenial bugs are detected.
ARM32 does not require this patch.
More info about the issue in this thread:
https://github.com/llvm/llvm-project/issues/65144
(From OE-Core rev: 12442b9b6df06317174066854935b1d6a4f1865d)
Signed-off-by: Thomas Roos <throos@amazon.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
zipfs is a new facility in tcl 9.x where various data files are bundled
into a zip archive, rather being separately installed.
Then that zip is embedded into libtcl.so from Makefile, thusly:
cat ${TCL_ZIP_FILE} >> ${LIB_FILE}
This is a major case of face meeting palm: any binary object
processing on the resulting .so file discards the extra data
at the end, and that's exactly what happens in do_package(),
resulting in a tcl installation without any language libraries.
This is not caught by ptest because it runs against a private
copy of the source tree.
Additionally, it helps to have data files on target systems
as files that can be viewed and edited.
(From OE-Core rev: 05e31be56498123b177f363c700c96b20958585c)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
From git 2.48 release notes:
"""
When "git fetch $remote" notices that refs/remotes/$remote/HEAD is
missing and discovers what branch the other side points with its
HEAD, refs/remotes/$remote/HEAD is updated to point to it.
"""
This means with git 2.48 onwards, there is a mystery "HEAD" revision
appearing in some of our shallow clone tests. We can avoid this by
using the same canonicalization as used for the reference revisions.
This resolves autobuilder failures on the Fedora 40 workers.
(Bitbake rev: c83444d1210740e27b1744d3aa7c5cad4e28db2f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage bbclasses . The loop looks like this:
kernel-fitimage.bbclass:
- do_populate_sysroot depends on do_assemble_fitimage
- do_assemble_fitimage depends on virtual/bootloader:do_populate_sysroot
- virtual/bootloader:do_populate_sysroot depends on virtual/bootloader:do_install
=> The virtual/bootloader:do_install installs and the
virtual/bootloader:do_populate_sysroot places into
sysroot an U-Boot environment script embedded into
kernel fitImage during do_assemble_fitimage run .
uboot-sign.bbclass:
- DEPENDS on KERNEL_PN, which is really virtual/kernel. More accurately
- do_deploy depends on do_uboot_assemble_fitimage
- do_install depends on do_uboot_assemble_fitimage
- do_uboot_assemble_fitimage depends on virtual/kernel:do_populate_sysroot
=> do_install depends on virtual/kernel:do_populate_sysroot
=> virtual/bootloader:do_install depends on virtual/kernel:do_populate_sysroot
virtual/kernel:do_populate_sysroot depends on virtual/bootloader:do_install
Attempt to resolve the loop. Pull fitimage configuration options into separate
new configuration file image-fitimage.conf so these configuration options can
be shared by both uboot-sign.bbclass and kernel-fitimage.bbclass, and make use
of mkimage -f auto-conf / mkimage -f auto option to insert /signature node key-*
subnode into U-Boot control DT without depending on the layout of kernel fitImage
itself. This is perfectly valid to do, because the U-Boot /signature node key-*
subnodes 'required' property can contain either of two values, 'conf' or 'image'
to authenticate either selected configuration or all of images when booting the
fitImage.
For details of the U-Boot fitImage signing process, see:
https://docs.u-boot.org/en/latest/usage/fit/signature.html
For details of mkimage -f auto-conf and -f auto, see:
https://manpages.debian.org/experimental/u-boot-tools/mkimage.1.en.html#EXAMPLES
Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies")
Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a patch to allow us to 'poison' system include directories,
which are warnings by default but we make them fatal in cross builds.
However, in the 13.1 upgrade[1] the patch to make the warnings fatal was
dropped in the compiler invocation, so it only took effect for pure
preprocessor calls. This was not noticed at the time as the test case
was flawed, but this has now been fixed.
Add back the fatal poisoning, and restructure the patch slightly so it
is less invasive.
[1] oe-core bea46612fd9106cc5b46eb1d81623b6492563c13
[RP: Tweak to fix gcc/gcc-cross-canadian failure]
(From OE-Core rev: 56f21a02c009cb74072ee79467a5bcab3c4643a5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test code in poison was flawed: as long as one CPP/CC/CXX has fatal
poisoning enabled then the test passes. However, at the moment due to
a bad rebase only CPP has fatal poisoning and CC/CXX do not.
Rewrite the do_compile() task to more carefully check the output so the
test harness itself just has to bitbake the recipe.
Note that this results in the test failing:
ERROR: poison-1.0-r0 do_compile: C Compiler is not poisoned.
Exit status 0, output: cc1: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories]
ERROR: poison-1.0-r0 do_compile: C++ Compiler is not poisoned.
Exit status 0, output: cc1plus: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories]
(From OE-Core rev: 5b413d1fdb4bdbaec86d630bb52c3ccf68aae789)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With gcc posioning fixed, this recipe showed errors, using an incorrect include
path looking at the host system. If pkgconfig is present, the correct include
paths are used. Therefore add the missing dependency.
(From OE-Core rev: 6cf0aaa3af276694709369b6007f629862e21559)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, providers are set on a global config basis. This change allows
for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS
on a per recipe basis. This would allow for the selection of virtual/cross-cc
as gcc or clang for example.
The PROVIDERS are removed from the recipes so that if a version of the
dependency accidentally slips through, the build will fail and the user
can correct the issue.
(From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, providers are set on a global config basis. This change allows
for a select set of providers configured in BB_RECIPE_VIRTUAL_PROVIDERS to
be selected on a per recipe basis. This would allow for the selection of
virtual/cross-cc as gcc or clang for example in OE-Core.
DEPENDS and task flag [depends] values are processed.
(Bitbake rev: fb119c7888ae8a749aa824f8c51780176af077f9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The git commit hashes for the kernel checkout are not reproducible under
certain conditions:
- If the git repository is initialized on an archive (rather than a
git), the initial git commit not only has the current user name set,
it also uses the current system time as committer and author date.
This will affect the initial git hash and thus all subsequent ones.
- The patches applied by the kern-tools have a valid author and date.
However, their committer again depends on the user building the BSP.
This is an issue, for example, if one compiles a kernel with
CONFIG_LOCALVERSION_AUTO enabled where the commit hash lands into the
kernel and thus the package version. This not only makes the package
version non-reproducible, but also leads to version mismatches between
kernel modules built against a fresh kernel checkout and the kernel
retrieved from the sstate cache.
The class uses 'check_git_config' from utils.bbclass, but this only sets
the git user and only if none existed before. Thus it doesn't really
help here.
Since in Git the committer information can be set only from the
environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and
GIT_COMMITTER_DATE, we introduce a helper function to set those and
apply the author settings in the same way.
As values simply use PATCH_GIT_USER_NAME, PATCH_GIT_USER_EMAIL (from
patch.bbclass) and SOURCE_DATE_EPOCH.
For convenience, put the new helper 'reproducible_git_committer_author'
into utils.bbclass next to 'check_git_config' so others can use it, too.
Using this helper in kernel-yocto.bbclass makes the committer and author
date/name/email for the initial commit reproducible, as well as the
committer name/email for the patches applied with kern-tools.
For debugging purpose, allow disabling the reproducibility features by
setting KERNEL_DEBUG_TIMESTAMPS to "1".
Suggested-by: Felix Klöckner <F.Kloeckner@weinmann-emt.de>
(From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
fmt-native is needed to build ccache-native, and the compile fails on
hosts with GCC 9.4 (such as Ubuntu 20.04). Backport a patch to fix this
issue.
(From OE-Core rev: 7dbb984f86d04e79d2311411cd8b775e2674b5f3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The linux-firmware now requires GNU Parallel in order to run parallel
builds. As the GNU Parallel is not a part of oe-core (the recipe is
present in meta-oe) disable parallel builds.
License-Update: additional files
(From OE-Core rev: 16e86b63696177a6f8b8f73b41e55dd6389f9e1c)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run systemctl preset-all with --global flag so user unit's are enabled
the same way system units are.
(From OE-Core rev: cdc3b3028f6d71788b5fdd99436f69fbf18f613e)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handle user units in a manner similar to system units where possible.
Not everything is supported by systemd, but systemd limitations only
affect runtime package management - during update user services are not
reloaded/restart and each user must re-login or manually restart
services.
(From OE-Core rev: ce62b88d8f71368e356b6409ada46a34a6017ddf)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since SYSTEMD_SERVICE_ESCAPED may contain both system and user services
we need to filter out user services in call to systemctl. Introduce
helper systemd_filter_services() which takes space-separated list of
services and returns services of requested type.
(From OE-Core rev: ec548b274d56b2c7a2663b70200df95a49e7452c)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously user units were handled the same way as system units, that
is all preset files were created in system-preset directory, but user
presets should be in user-preset directory.
(From OE-Core rev: 0218542d80723ec314a648af8e9649806c3a51aa)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
systemd_service_searchpaths accepts boolean value indicating whether we
are dealing with system or user units and returns search paths
accordingly.
Previously search path list was created in systemd_check_services() but
following commits will introduce additional places. The
systemd_service_searchpaths helper function is meant to reduce code
duplication.
(From OE-Core rev: 9a89d36932dda306b3c2cf10771647eabc267769)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Factor out the logic into systemd_service_path(). This will be needed by
following commits to avoid code duplication.
(From OE-Core rev: d383e18138050490f3dcb95377f63a2a31c3149f)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We already search for system units ${sysconfdir}/systemd/system but we
don't search for user units in corresponding directory under ${sysconfdir}.
Keep the behaviour consistent so that both unit types are searched in
${systemd_{system,user}_unitdir} and ${sysconfdir}/systemd/{system,user}.
(From OE-Core rev: df1cdf1bf4cd7d9f17c6a02538057ccfc2efba64)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The flag is similar to --user flag as it causes systemctl to operate on
user units, but it performs operations globally for all users. This is
required for user presets support.
(From OE-Core rev: ab6476d28485598ae842472a7b15ca7bf244c776)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Linux kernel commit 48bff1053c17 ("random: opportunistically initialize
on /dev/urandom reads") introduced a change where /dev/urandom blocks if
the random pool is insufficiently initialized during hardware boot. This
behavior causes /dev/urandom reads to hang for approximately 5 seconds,
delaying the boot process with eudev init script (when it calls udevd).
This issue has already been solved upstream, therefore backport the
upstream patch to fix this.
(From OE-Core rev: cd5f630581f3e38645a92ad75b496bce92b679cb)
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't run reproducible-builds on specific distros anymore, but on a
distro at random depending on what is available on the Autobuilder. Fix
the link to this builder and remove distro specific ones.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 8bd2bc3c00ca80f4c000a2a8d618a9f8ea3aa54b)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have moved to Valkyrie which is hosted on
https://autobuilder.yoctoproject.org/valkyrie. Update the URL in the
documentation.
Also, the YOCTO_AB_URL macro was used in a single location in the
documentation so replace it by the :yocto_ab: custom extlink and remove
the macro.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 0b0ed55d909dd11cdc9b29b105473271627c025e)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a fix for 22dc5b3be3b1fbdb9447999b71f79db055271826, which has
completely replaced debug-tweaks. But in the context of devtool ide-sdk
and the comment in the example, the post-install-logging-image feature
doesn't really make much sense. Therefore, remove it.
(From yocto-docs rev: 148191460627241cbd0c42583140f114c78cc94c)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_create_extlinux_config is using a bit of an odd mechanism which
doesn't work well with sstate cache invalidation.
BitBake will detect changes to UBOOT_EXTLINUX_FDTOVERLAYS because it's
explicitly mentioned in the task, but it'll miss changes to
UBOOT_EXTLINUX_FDTOVERLAYS:label because this OVERRIDES is set within
the task, so the value of UBOOT_EXTLINUX_FDTOVERLAYS for the label
OVERRIDES will only ever change from within the task, while it is
running, much later than during parsing.
For that to work properly, we need to add the entire variable (including
the OVERRIDES part) to the vardeps varflag of the task so that its value
is monitored. This is already done for all possible label variables but
FDTOVERLAYS was forgotten.
Fixes: 3ac21b32b5f5 ("uboot-extlinux-config.bbclass: add support for DTBOs")
(From OE-Core rev: a41fd633786a2404b5eee399ed0602e229c4be77)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Until now, the default title of a boot entry is its label. The label is
a variable which determines the script to run during an early boot stage
and is not necessarily human readable.
This patch allows to provide a human-readable title for each boot entry.
(From OE-Core rev: a5a7f6ada786b7f2c1a317f20b7e642f1e978de9)
Signed-off-by: Simon A. Eugster <simon.eu@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Convert from autotools to meson.
Drop tmpdir.patch (replaced by -Dtest_socket_dir=/tmp --Dsession_socket_dir=/tmp).
License-Update: license texts split into separate files, SPDX ids added.
(From OE-Core rev: b0241aa9b1ecc38be1ca016f36075552a2eba48a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Despite the name, autotools_aclocals() doesn't actually do anything with
aclocal. Instead it reads all of the available autoconf site default
files[1] and sets CONFIG_SITE appropriately. Rename the function to
autotools_sitefiles to make this clear.
Also there's no need to do this before do_configure or do_install, as
the variable is only checked when configure runs.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html
(From OE-Core rev: 05080b48a9607e19a251c7396c1b06f08d98ed3b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable no longer exists, and would have had the effect of not
letting the target libtool see the contents of the native aclocal
directory.
I don't understand why this was needed but autotools has improved
dramatically in the last eight years, so it's most likely obsolete now.
(From OE-Core rev: 8ae468b6726392c681a3a35ff37c4401ec45b9d2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need aclocal to look in two different $datadir/aclocal/ directories:
the native (eg, for pkg.m4 from pkgconfig) and the target (eg, for
alsa.m4 from alsa-lib).
aclocal doesn't directly support this pattern, currently we use
--system-acdir to specify the target directory and then add the native
directory to the user include list.
However, since automake 1.17 there is also an --aclocal-path option to
augument the search list. As the relocated aclocal from automake-native
already knows the correct path for the native aclocal directory we can
use --aclocal-path to add the correct target aclocal directory.
For simplicity I don't bother only doing this in non-native builds as
this just adds the same path to the search twice.
This removes ACLOCALDIR and ACLOCALEXTRAPATH. Recipes using these to
add search paths should instead use EXTRA_AUTORECONF += "-I path".
(From OE-Core rev: 878e1517d4890b31332a506ce903d57e1d7dff87)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream does not want the pam tests to be skipped
(From OE-Core rev: 7c5baaf8b95422ad0192ba3dc93efadf5eb70476)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ide-sdk command bootstraps the SDK from the bitbake environment
before the IDE configuration is generated. In the case of the eSDK
installer, the bootstrapping is performed during the installation of
the eSDK installer. Running the ide-sdk plugin from an eSDK installer
based setup would require skipping the bootstrapping and probably taking
some other differences into account when generating the IDE
configurations.
This would be possible. But it will probably never be implemented, as
running devtool ide-sdk directly from the bitbake environment is much
more flexible.
Also, some of the recent improvements that have made it into the core
have the potential to make the eSDK installer obsolete at some point in
the future:
- bitbake-layers create-layers-setup replicates the layers
- bitbake-config-build replicates the build configuration
- The new sstate mirror features replicate the sstate
- bblock locks the sstate more flexible than the eSDK installer
- devtool ide-sdk bootstraps the SDK directly from the bitbake
environment. The same environment-setup... file is provided with
--mode=shared.
The devtool modify based workflow is supported since always by devtool
and also the default --mode of devtool ide-sdk.
These functions essentially cover what the eSDK installer does without
a need for the current implementation of the eSDK installer and the
populate_sdk_ext, which is hard to maintain and takes a lot of time to
build.
This means that instead of making the ide-sdk plugin compatible with the
eSDK installer, we should rather replace the current implementation of
the eSDK installer and populate_sdk_ext with an implementation that can
replicate a normal bitbake environment in a convenient way where the
ide-sdk plugin also just works without additional complexity.
(From OE-Core rev: 177aa72b37f2061ff3311ec5dbb33aa56a5ba006)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These imports are not needed.
(From OE-Core rev: c0e9e35843004aaac5bdcc12fa1f6bf8d2da0abb)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The error described does not occur in all cases where libxkbcommon is
used. As example, a Qt application that depends on libxkbcommon might
not require any locales to be installed.
Add it to RRECOMMENDS, as libxkbcommon does not seen to have any hard
dependency on libx11-compose-data or libx11-locale. This change can help
users decide to disable it and save some space on the rootfs.
(From OE-Core rev: 58f92b66243a4f6aec9d3890b4d6c3d0ae0dc4d0)
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Twelve years ago, libtool on Debian had a patch that meant it failed to
cross-compile lttng-tools correctly. The solution at the time was to
sed libtool.m4 whilst configure was being ran[1], which (assuming it
patches the correct file) results in a re-execution of configure during
do_compile.
This behaviour is undesired as we don't patch libtool in the way that
this fixup is needed (the sed only changes Haiku OS codepaths), so
disable it.
[1] 6bd5984c2b
(From OE-Core rev: 87c1c7aa306759183e1f0b67a813b58eed8fb8ad)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 3.0.1 release of SPDX has been officially released with a few minor
modifications. Regenerate the bindings to use this version.
(From OE-Core rev: 54233a7d6fe414d22449fb02fac26b66a820b17a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #15625]
The first attempt to get around the timeout was to double it from 5000
to 10000, which doesn't seem to be enough. Let's try to fix this by
extending the timeout by a factor of 10.
(From OE-Core rev: fb19e038582a2bfc414465ef396c30197f67128f)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
