This had specific uses a long time ago but hasn't been maintained and is now out
of date to the point of being questionable value. Drop it.
(From OE-Core rev: f911cf3beb9b7a761b75c676238df69eb92a6c2b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This version is deprecated and replaced by babeltrace2. Drop the older version
so we can focus efforts around the newer one.
(From OE-Core rev: d16a5e05b3f383d21a1970c6613494416a7503c2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was originally applied as our autobuilder had older hardware and couldn't
cope with the newer settings. This has been resolved in the new cluster so we
can go back to the newer tuning, which software is now more likely to need.
This reverts commit 369b1dfa28b1791d45f068acc765190defecd460.
(From OE-Core rev: c9585bb8689b6089ce3870910b2dbdb7e9aa547a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
crypto is optional on armv8a and Broadcom BCM2837 SoC found on
rpi3 does not have hardware acceleration for cryptographic operations.
(From OE-Core rev: ef0a34580e71b28a27dcf75285c727fc55c240fc)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Jon Mason <jon.mason@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a `nocrypto` TUNE_FEATURE option to `feature-arm-crypto.inc`
to explicitly disable ARM crypto extensions via GCC flags. This
provides an opposing state to the existing `crypto` feature,
enabling more explicit control over crypto-related tuning.
Some vendors ship cores without crypto support, and this change
allows disabling it without requiring extensive audits of
dependent code paths. This approach avoids the knock-on effects
caused when `nocrypto` is applied implicitly in the absence of
`crypto` in TUNE_FEATURES.
TUNECONFLICTS was added to prevent both features from being
enabled simultaneously. When both are added, the following error
is seen during build:
Feature 'nocrypto' conflicts with 'crypto'.
Feature 'crypto' conflicts with 'nocrypto'.
(From OE-Core rev: 51e0da4db61abcc546af216609f172204ddb17ab)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Cc: Ryan Eatmon <reatmon@ti.com>
Cc: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We now need the new bitbake setVarFilter function. There was also some
changes to bb.event.check_for_interrupts() which changed in an
incompatible way.
(From OE-Core rev: 9840877cb7dc9c57c65a2b2740121a8c56b9985b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added it to slow tests, as it takes betwen 165 and 190 seconds on my
machine to execute (qemux86-64 + kvm).
The test folder's Makefile contains a list of passing, failing and manual
tests. By default, only the expected-to-pass tests are executed by the
Makefile (unless magic environment variable is set).
The run-ptest script mimics the default behavior of executing the
expected-to-pass tests, however they are executed one by one, instead of
running them as one batch - that way it is easier to determine exactly
which tests pass and which fail.
One other thing that might worth a note, is that the tests folder that needs to be
installed contains a number of subfolders called "DEBIAN". When packaging them
at least with rpm, these folders are omitted from the package.
However these are essential for the tests, as they contain test data. As a
workaround, these folders are renamed during installation to DEBIAN-ptest,
and before execution the run-ptest script restores their names.
(From OE-Core rev: 02ed7fad85463840c46b6c0fa0ac9decef77c503)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch our default qemu images to use .zst compressed images by default
since this is the output format we release during the release process
and is the one that users would prefer to download. This makes the release
process use the actual generated output from the system and avoids post
processing.
(From OE-Core rev: aa5f60d1fcb716a2b2174dffcaf35442bff1f1fb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* GCC 12.1 or later is now required to build the GNU C Library.
* GNU Binutils 2.39 or later is now required to build the GNU C Library.
* Support for lightweight stack guard pages via madvise and the
MADV_GUARD_INSTALL flag has been added to pthread_create.
* This is major release, changelog [1]
[1] https://sourceware.org/pipermail/libc-announce/2025/000048.html
(From OE-Core rev: 7c55e2da96f40ee0e40f6fd534573ce64013145c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The lld linker is a standalone project under the LLVM umbrella that just
depends on libLLVM and nothing else, such as clang.
To reduce the build time of clang if lld is not being used, split it out
into a separate recipe.
To ensure that lld is present if needed, the clang-cross recipe will
depend on lld-native if ld-is-lld is enable.
(From OE-Core rev: 5212b69f892af8c9b080fee2c21533a2bbdd2755)
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>
When crypto is not in tune features then add +nocryto to
-mcpu explicitly. This makes the behavior between clang
and gcc match. Currently -mcpu=cortex-a72 has different
behavior in clang and gcc in terms of what features are
considered default. Clang enables different set of common
features than gcc on other hand. For example clang
enables crypto with default set but gcc
does not, gcc recommends to disable unavailable extensions
in -mcpu [1] explicitly. crypto is optional on cortex-a53
and cortex-a72. This is not as common but Broadcom
SOCs in raspberrypi3/4 have dropped crypto for cost
reasons [2]. This results in illegal instruction
traps [3] [4] when building components e.g. chromium,
qtwebengine, weston etc. with clang using -mcpu=cortex-a72
for rpi4 target.
Adding +nocrypto makes clang behave like gcc does today. We
do have separate tune if crypto enabled cortex-a72 cores
are to be targeted (cortexa72-cryto) as DEFAULTTUNE
They are added to default feature file since crypto extension
is available in multiple arm architecture versions e.g. armv8,
armv9. It is optional extension as per spec [5]
Extensions can be enabled and disabled with -mcpu using the same
syntax as with -march, and have same effect thats why it is
intrumented via TUNE_CCARGS_MARCH_OPTS
[1] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mcpu-2
[2] https://forums.raspberrypi.com/viewtopic.php?f=63&t=207888#p1332960
[3] https://github.com/llvm/llvm-project/issues/85699
[4] https://github.com/llvm/llvm-project/issues/90365
[5] https://developer.arm.com/documentation/109697/2025_06/Feature-descriptions/The-Armv9-0-architecture-extension
(From OE-Core rev: db1b355b2b15ba57bd89c2dfb88c2c667551863e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Quentin Schulz <quentin.schulz@cherry.de>
Acked-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>
The uninative tarball requires xz to decompress:
WARNING: Disabling uninative as unable to install uninative tarball:
WARNING: tar (child): xz: Cannot exec: No such file or directory
(From OE-Core rev: 9c0bc6edf5e6706597563924f62bbab6fdd38ac2)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rust stable version updated to 1.88.0.
https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/
* Rebase existing patches with v1.88.0
* Exclude tidy and coverage-dump from OE self-tests due to test failures
Although the build completes successfully, OE self-tests fail:
tools/coverage-dump panics during test execution.
tools/tidy fails due to a mismatched GCC submodule commit.
These tests are excluded to allow successful OE self-test runs.
* Two tests from the`codegen` modules now fail only on riscv64.
Enable them on arm32/64 and x86-32/64 targets, while restricting
them on riscv64 via `only-<target_arch>` tags.
Bugzilla link - https://bugzilla.yoctoproject.org/show_bug.cgi?id=15944
Test Results Summary:
+-----------+--------+---------+
| Machine | Passed | Ignored |
+-----------+--------+---------+
| arm-32 | 28,664 | 1,451 |
| arm-64 | 28,748 | 1,396 |
| x86-32 | 28,657 | 1,432 |
| x86-64 | 28,904 | 1,213 |
| riscv-64 | 28,722 | 1,421 |
+-----------+--------+---------+
(From OE-Core rev: 5afc9bdbabfdbcb784ceb637926111e6c7648f41)
Signed-off-by: Jayasurya Maganuru <Maganuru.Jayasurya@windriver.com>
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move some environment variables to the configuration file, so there's
less happening in the class.
Max_size was removed so that the per-recipe caches don't grown without
limit. The default cache is 5GB.
(From OE-Core rev: 8c1c38a6b3073d2dd34514f5a90805c12c0f42dd)
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>
Split the libclc subproject out of the clang recipe and into a dedicated
libclc recipe.
This is useful because libclc is the OpenCL runtime library and as such
isn't target-specific and needs a native clang to build, not a target
libllvm.
Verified that nothing is dropped by adding clang and libclc to an image
and verifying that the file list is the same before and after this
change.
We need to patch the libclc CMakeLists to allow it to use an out-of-tree
prepare_builtins binary, discussion is ongoing with upstream to resolve
this properly.
(From OE-Core rev: 33a8742a1280b4c6779a7aa487c2dd4a713babe6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
clang doesn't have Arm big.LITTLE specific tune options - when such an option is used,
the compilation fails with an error like this:
aarch64-poky-linux-clang: error: unsupported argument 'cortex-a72.cortex-a53+crc+crypto' to option '-mcpu='
To avoid this, in case a big.LITTLE SoC is the target and the toolchain is clang, select
the tune corresponding to the LITTLE core.
(From OE-Core rev: 12c820f624730a04a17ae2cdbecc4e6987c45cf7)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add following patches.
- 0001-test-Add-support-ptest.patch
- Some default paths in test code are invalid at runtime and cause
- test failures. So add a patch to adjust path to test data for ptest
- environment.
- 0001-ICU-23120-Mask-UnicodeStringTest-TestLargeMemory-on-.patch
- Since ICU-77.1, a test case (TestLargeMemory) that fails to build
- in a 32-bit environment. So add a patch to skip this test case.
- This bug has been reported to upstream. See https://unicode-org.atlassian.net/browse/ICU-23120.
Install icu test-suite to run it as a ptest.
Add icu to PTESTS_FAST because it takes 27sec (less than 30sec) to complete on
qemux86-64 with kvm enabled.
root@qemux86-64:~# ptest-runner icu
START: ptest-runner
2025-07-06T00:46
BEGIN: /usr/lib/icu/ptest
___(snip)___
--------------------------------------
Elapsed Time: 00:00:23.070
PASS: ./intltest
DURATION: 27
END: /usr/lib/icu/ptest
2025-07-06T00:47
STOP: ptest-runner
TOTAL: 1 FAIL: 0
(From OE-Core rev: 4a729a529067a5ba7036a224cf330e31b8a5f838)
Signed-off-by: Daisuke Yamane <yamane07ynct@gmail.com>
CC: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Brings following fixes
* 87f0227cb601 [InstCombine] Avoid folding `select(umin(X, Y), X)` with min/max values in false arm (#143020)
* df43f93388b7 [PhaseOrdering] Add test for #139050 (NFC)
* 25bcf1145fd7 [RISCV] Fix assertion failure when using -fstack-clash-protection (#135248)
* 6fb913d3e2ec [RelLookupTableConverter] Drop unnamed_addr for GVs in entries to avoid generating GOTPCREL relocations (#146068)
* 0c9f909b7976 [AArch64][SME] Fix restoring callee-saves from FP with hazard padding (#143371)
* fa792cd4c630 [AsmPrinter] Always emit global equivalents if there is non-global uses (#145648)
* ce455b382c08 [objcopy][MachO] Revert special handling of encryptable binaries (#144058)
* 0de59a293f7a [X86] Ignore NSW when DstSVT is i32 (#131755)
* 9af763f038f7 [gtest] Fix building on OpenBSD/sparc64 (#145225)
* 1daceb20611f [LoongArch] Pass OptLevel to LoongArchDAGToDAGISel correctly
* b21155f97a0a [LoongArch] Precommit test case to show bug in LoongArchISelDagToDag
* da18fb9f04ce [LoongArch] Fix xvshuf instructions lowering (#145868)
* 65ce78f338cf [LoongArch] Pre-commit test for fixing xvshuf instructions. NFC
* 5532d5b745e4 [AArch64] Ensure the LR is preserved if we must call __arm_get_current_vg (#145760)
* 5ac3ce819688 [WebAssembly] Fix inline assembly with vector types (#146574)
* b83658b7e2c8 Bump version to 20.1.8
(From OE-Core rev: 4c6e132d6e5e49426c911d0fa9215957eb43f186)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since OE-Core rev: cc83e45484656a6b577ff84817131735023daad4
the STAMP value and STAMPCLEAN glob have been mismatched. The
issue is present since the PR part was removed from the STAMP variable
in that comit.
An example use case that I found was broken due to this:
1. Have recipes foo_A.bb and foo_B.bb
2. Build foo-native with PREFERRED_VERSION_foo-native = "A"
3. ${COMPONENTS_DIR}/x86_64-linux/foo-native has version A
4. Build foo-native with PREFERRED_VERSION_foo-native = "B"
5. ${COMPONENTS_DIR}/x86_64-linux/foo-native has version B
6. Build foo-native with PREFERRED_VERSION_foo-native = "A"
7. ${COMPONENTS_DIR}/x86_64-linux/foo-native still has version B
In my case the PREFERRED_VERSION comes from different machines.
The issue showed itself when a bar-native compiled against foo-native
version A was pulled from sstate-cache and foo-native in version B was
kept in ${COMPONENTS_DIR} after previous build for a different machine.
The two variables should be in sync and this patch corrects that.
[RP: Tweak commit message]
(From OE-Core rev: 932be19f48735d72a72de2771911119433956f4f)
Signed-off-by: Michal Sieron <michalwsieron@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LLDB takes a reasonable amount of time to compile, but also isn't an
essential component of the LLVM suite.
Instead of always building it when we build clang, split it out into a
separate recipe.
On my build machine where clang takes 21 minutes to build with lldb, it
takes 19 minutes without lldb.
(From OE-Core rev: 9da4900aa5a37718bd42f277d5a1805ec897b1b4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building the LLVM projects often means using the TableGen tools
(llvm-tblgen etc).
We currently build them as part of clang-native, but I am teasing the
clang recipe into its component parts and having to build llvm-native
or lldb-native simply for one tool isn't ideal.
Instead, add a native recipe that simply builds the tablegen binaries
for llvm, clang, and lldb
(From OE-Core rev: fbf63e03fe09ca74022c9d06442b4f1021b71d57)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this fix:
devtool deploy-target cmake-example qemu1 --strip
...
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so.1.0.0': Operation not permitted
cp: failed to preserve ownership for ...cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so.1: Operation not permitted
cp: failed to preserve ownership for ...cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so: Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/lib': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin/cmake-example': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin/test-cmake-example': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped': Operation not permitted
tar: ./usr/lib/libcmake-example-lib.so.1.0.0: time stamp 2025-07-06 16:46:06 is 0.527890738 s in the future
tar: ./usr/lib/libcmake-example-lib.so.1: time stamp 2025-07-06 16:46:06 is 0.527462566 s in the future
tar: ./usr/lib/libcmake-example-lib.so: time stamp 2025-07-06 16:46:06 is 0.526732779 s in the future
tar: ./usr/lib: time stamp 2025-07-06 16:46:06 is 0.526415655 s in the future
tar: ./usr/bin/cmake-example: time stamp 2025-07-06 16:46:06 is 0.52568721 s in the future
tar: ./usr/bin/test-cmake-example: time stamp 2025-07-06 16:46:06 is 0.525054415 s in the future
tar: ./usr/bin: time stamp 2025-07-06 16:46:06 is 0.524821739 s in the future
INFO: Successfully deployed .../cmake-example/1.0/devtool-deploy-target-stripped
With this fix:
devtool deploy-target cmake-example qemu1 --strip
...
INFO: Successfully deployed .../cmake-example/1.0/devtool-deploy-target-stripped
This is most probably related to the commit:
2502da81709f25de499277b28d33c915638c45f6
bitbake.conf/pseudo: Switch from exclusion list to inclusion list
(From OE-Core rev: 8b42b698ea13e1951f7bac4ddd89e13c9b0cb3a6)
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>
Instead of hard coding the VEX justifications for "Ignored" CVE status,
add a map that configures what justification should be used for each
status.
This allows other justifications to be easily added, and also ensures
that status fields added externally (by downstream) can set an
appropriate justification if necessary.
(From OE-Core rev: c0fa3d92cefa74fa57c6c48c94acc64aa454e781)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for tinfoil and umask helper function changes.
(From OE-Core rev: d1c39b29f21719b349072c51a761fa19770a49ea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the "shared" directory permissions of sstate are hardcoded. Since
multiple areas of the code reference this, separate it out to a variable to
allow the behaviour to be configurable. Initially this applies to SSTATE_DIR.
(From OE-Core rev: ce32daa9843bcb5f6daf3560c64ca9e5144adcb0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add python3-packaging to RDEPENDS
* Enable ptest:
- Add to ptest-packagelists.inc PTESTS_FAST
- inherit ptest-python-pytest
- Add python3-setuptools to ptest RDEPENDS
- One test is skipped, but it requires the "full" python3-flit,
not just python3-flit-core.
Comparing changes since 0.45.1:
https://github.com/pypa/wheel/compare/0.45.1...0.46.1
Release notes [1]:
0.46.1 (2025-04-08)
* Temporarily restored the wheel.macosx_libfile module (#659)
0.46.0 (2025-04-03)
* Dropped support for Python 3.8
* Removed the bdist_wheel setuptools command implementation and entry
point. The wheel.bdist_wheel module is now just an alias to
setuptools.command.bdist_wheel, emitting a deprecation warning on import.
* Removed vendored packaging in favor of a run-time dependency on it
* Made the wheel.metadata module private (with a deprecation warning if
it’s imported
* Made the wheel.cli package private (no deprecation warning)
* Fixed an exception when calling the convert command with an empty
description field
[1] https://wheel.readthedocs.io/en/stable/news.html
(From OE-Core rev: 610ca66283b6a440a1cde4c26945392ed15ac3e0)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The sphinx-copybutton extension can be used to add a copy button to code
blocks in the documentation.
(From OE-Core rev: ebf14a6dc1a5fd041f4df4fd8c6f28da9d15c8f6)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This Sphinx extension can be used to autogenerate documentation for any
python module returning an argument parser from argparse. It can used in
places of the documentation where the --help output is currently
hardcoded, and generate formatted documentation instead.
(From OE-Core rev: 84d1a347195a3cd702468b01a71e787c3e007488)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rust stable version updated to 1.87.0.
https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/
* Update LLVM data-layout for arm64.
LLVM requires matching data layouts and
the aarch64 llvm data-layout was updated to to allow using
32-bit signed/unsigned pointers when building 64-bit targets
using 270, 271 and 272 address spaces.
e985396145c9f27275c1
* Rebase existing patches with v1.87.0.
* Two tests from the `ui` and `codegen` modules now fail only on riscv64.
Enable them on arm32/64 and x86-32/64 targets, while restricting
them on riscv64 via `only-<target_arch>` tags.
Test Results Summary:
+-----------+--------+---------+
| Machine | Passed | Ignored |
+-----------+--------+---------+
| arm-32 | 28,320 | 901 |
| arm-64 | 28,400 | 849 |
| x86-32 | 28,285 | 885 |
| x86-64 | 28,518 | 676 |
| riscv-64 | 27,845 | 868 |
+-----------+--------+---------+
* Backport triagebot.patch to skip tidy linkcheck when triagebot.toml
is not present. Distribution tarballs won't include triagebot.toml,
which causes tidy checks to fail.
This backport ensures tidy checks can still run successfully
even when the file is missing.
https://github.com/rust-lang/rust/pull/142666/commits
* During rust installation, some binaries were installed from
'stage2-tools' built path to '${D}${bindir}'. However, from
v1.87 the stage2-tools are no longer built by default.
Update logic to install from `stage1-tools` instead.
(From OE-Core rev: 16ce25e6970b4a50f6433606a0c87d22ec74ea5a)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If GLVND is enabled, then libglvnd is providing all OpenGL / ES
libraries. Tune default-providers.inc to select a correct package in
this case.
(From OE-Core rev: 28bc66ade84241f3f9b680d5c1fd8d261da4b413)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libglvnd is a vendor-neutral approach to handling OpenGL / OpenGL ES /
EGL / GLX libraries. It has been proposed and initially implemented by
NVIDIA in order to simplify coinstallation of GL drivers provided by
different vendors. Major Linux distributions (Debian, Ubuntu, Fedora,
etc.) have already switched to libglvnd.
Having libglvnd in OE-Core simplifies integration of this ABI into
distro and BSP layers (e.g. it will help meta-tegra, which currently
provides its own version of the recipe).
Import recipe for libglvnd from the meta-oe layer (changes: fix virtual
package names, add add the SUMMARY data, drop git@ from SRC_URI, require
glvnd DISTRO_FEATURE).
(From OE-Core rev: 621e9be9663e448dde3f6b6a02b413fd65983e6c)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
default-providers.inc already includes PREFERRED_PROVIDER values for
xserver and GL libraries. Drop the same values being set in the machine
config.
(From OE-Core rev: 973875c79476b70edbef8976446de1be29d50910)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
default-providers.inc already includes PREFERRED_PROVIDER values for
xserver and GL libraries. Drop the same values being set in the machine
config.
(From OE-Core rev: 589a49c7bd68465163a86e71a67f518849860804)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
default-providers.inc already includes PREFERRED_PROVIDER values for
xserver and GL libraries. Drop the same values being set in the machine
config.
(From OE-Core rev: 882e8c3cf28b33cdd6cb26ec412e63a0da8a3199)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The virtual-{libegl,libglx}-icd names are RPROVIDES, not PROVIDES,
because they are a runtime dependency of libglvnd. Make
default-providers follow that and specify PREFERRED_RPROVIDER instead of
PREFERRED_PROVIDER for those names.
Fixes: 9d3b4c9bc403 ("mesa: sort out PROVIDES for the glvnd case")
(From OE-Core rev: c2b4971e79ece23c43639865a617ee4c248fa981)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since there are currently multiple breaking changes, update to a new
release series for the next release so layers can show compatibility
correctly.
(From OE-Core rev: 75eb26e71dba4096d5632b7f6b13db4f13aa6d7f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of them were introduced by mass-removal of S = WORKDIR/git assignments;
rather than try to fix up (or redo) just these, I've run this sed command over
the whole tree:
sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name *.bb -o -name *.inc`
The rationale is that more than one empty line is wasting vertical screen space, and
does nothing for readability.
(From OE-Core rev: cedc4ff7c9bcfb22a20e43e47f9759f4007a4f1a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This transitions most of the recipes to have their sources
in UNPACKDIR, which over time will allow more simple and logical
source code handling in various pieces of the Yocto project.
(From OE-Core rev: 50439f56b2d94769de928c70eebdfd4b47794fb4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is shorter and doesn't include the unnecessary task name, just the
result of it: source trees and files.
(From OE-Core rev: f19ea21c8ebf8ce211b14e69b27c82faf080185a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
