Although rust differs between compiling (--> 'rust-cc' wrapper) and
linking (--> 'rust-ccld' wrapper), some core crates are using only the
'rust-cc' wrapper to check for available compiler options [1] and
libraries [2].
Not having LDFLAGS can break the build in subtle ways. E.g. 'cargo-native'
can fail to build with
| = note: .../hosttools/ld: .../liblibz_sys-....rlib(deflate.o):
| relocation R_X86_64_32S against hidden symbol `_length_code' can not be used when making a PIE object
because it does not find '-lz' (added by "DEPENDS = zlib") and builds
a static libz.a with missing PIC flags.
Add LDFLAGS to the 'build-rust-cc' wrapper as it is done already for
the target one.
[1] https://github.com/rust-lang/cc-rs/pull/1322
[2] 12a32798c6/build.rs (L228-L234)
(From OE-Core rev: 49b37575b548f0ab082c700f91fdd856740dc829)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Commit f82d9c997ba (systemd: enable create-log-dirs) removed the
creation of the /var/log/README symbolic link by using sed. However, the
update to 257 changed the target line and the sed expression no longer
matches. Rather than correcting the sed expression, use a patch to
remove /var/log/README so that any future changes do not go unnoticed.
(From OE-Core rev: 76cf5994262f9fd76cf27e111eb67ad1645541f1)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
This patch introduces the following packages for AMD gpu chips:
- linux-firmware-amdgpu-aldebaran
- linux-firmware-amdgpu-carrizo
- linux-firmware-amdgpu-cezanne
- linux-firmware-amdgpu-fiji
- linux-firmware-amdgpu-hawaii
- linux-firmware-amdgpu-navi10
- linux-firmware-amdgpu-navi14
- linux-firmware-amdgpu-navi21
- linux-firmware-amdgpu-navi22
- linux-firmware-amdgpu-navi23
- linux-firmware-amdgpu-navi24
- linux-firmware-amdgpu-navi31
- linux-firmware-amdgpu-navi32
- linux-firmware-amdgpu-oland
- linux-firmware-amdgpu-polaris10
- linux-firmware-amdgpu-polaris11
- linux-firmware-amdgpu-polaris12
- linux-firmware-amdgpu-raven
- linux-firmware-amdgpu-rembrandt
- linux-firmware-amdgpu-renoir
- linux-firmware-amdgpu-stoney
- linux-firmware-amdgpu-tonga
- linux-firmware-amdgpu-topaz
- linux-firmware-amdgpu-vega10
- linux-firmware-amdgpu-vega12
- linux-firmware-amdgpu-misc: catches all firmwares that are not
already included in the other -amdgpu- packages.
This list was partly inspired from:
https://wiki.gentoo.org/wiki/AMDGPU#Known_firmware_blobs
Many other firmware packages could be created out of what is in
-misc. Looking at the different commits in the linux-firmware
repository gives a very good idea of which firmware goes with each
chip.
Note: Altough this patch might break some installations that assumed
that _all_ firmwares where installed by the linux-firmware-amdgpu
package, I think it is a step in the right direction as the number of
firmwares under amdgpu is constantly increasing (currently ~103MB).
Tested with a renoir gpu.
(From OE-Core rev: 4bcb1cd5803d7b664140f177730af3c0e0b60968)
Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
This patch introduces the following packages for ath11k based chips:
- linux-firmware-ath11k-ipq5018
- linux-firmware-ath11k-ipq6018
- linux-firmware-ath11k-ipq8074
- linux-firmware-ath11k-qca2066
- linux-firmware-ath11k-qca6390
- linux-firmware-ath11k-qcn9074
- linux-firmware-ath11k-wcn6750
- linux-firmware-ath11k-wcn6855
- linux-firmware-ath11k-misc: catches all firmwares that are not
already included in the other -ath11k- packages (currently empty).
linux-firmware-ath11k is now a meta package that depends on all of the
split-out ath11k packages.
(From OE-Core rev: 635f0cc49f91b79b1cee40e2825514d7ce474d32)
Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
This patch introduces the following packages for ath10k based chips:
- linux-firmware-ath10k-qca4019
- linux-firmware-ath10k-qca6174
- linux-firmware-ath10k-qca9377
- linux-firmware-ath10k-qca9887
- linux-firmware-ath10k-qca9888
- linux-firmware-ath10k-qca988x
- linux-firmware-ath10k-qca9984
- linux-firmware-ath10k-qca99x0
- linux-firmware-ath10k-misc: catches all firmwares that are not
already included in the other -ath10k- packages (currently empty).
linux-firmware-ath10k is now a meta package that depends on all of the
split-out ath10k packages.
(From OE-Core rev: 18b0b076e749bf8684958acf1a97504a69f73edd)
Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
LIC_FILES_CHKSUM supports begin-/endline for licenses included in
for instance header files. This patch adds support for line numbers
to NO_GENERIC_LICENSE, too.
(From OE-Core rev: 8e7ee19fc9e74cf042880f4bc317782482ba6f66)
Signed-off-by: Denis Osterland-Heim <denis.osterland@diehl.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
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>
