bitbake-setup conf.json can be purely template driven, to setup older
yocto LTS (e.g. scarthgap) based layer-collections - where fragment
support was not yet present in oe-core+bitbake.
Add a configuration for that scenario and add it to the test routine.
(Bitbake rev: 23e121befa0779fbb1f342984b583c04ccc637a0)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds support for extending the BB_ENV_PASSTHROUGH_ADDITIONS
environment variable from within the `init-build-env` wrapper script -
generated by either oe-core's oe-setup-build, or by `bitbake-setup` -
based on per-configuration JSON settings.
This enables CI workflows to inject environment-specific data - such
as build number, host, build type, or credentials required to fetch
from certain SRC_URIs - which cannot be captured via configuration
fragments alone. These variables are now handled early in the setup
process and exported directly into the build environment.
Example:
"bb-env-passthrough-additions": [
"ACME_DIR",
"ARTIFACTORY_TOKEN",
"ARTIFACTORY_USERNAME",
"GITHUB_TOKEN",
"GITHUB_PROTOCOL",
"KEY"
]
<snip>
the resulting 'init-build-env' would then be:
# environment passthrough added by bitbake-setup
export BB_ENV_PASSTHROUGH_ADDITIONS=" \
$BB_ENV_PASSTHROUGH_ADDITIONS \
ACME_DIR \
ARTIFACTORY_TOKEN \
ARTIFACTORY_USERNAME \
GITHUB_TOKEN \
GITHUB_PROTOCOL \
KEY"
# init-build-env wrapper created by bitbake-setup
. /tmp/acme_master-acme-distro_acme-machine_bang/layers/openembedded-core/oe-init-build-env /tmp/bitbake-setup/gs/acme_master-acme-distro_acme-machine_bang/build
(Bitbake rev: 782ab99e7a04fba43bdcf5763a6280785944ae3f)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In autobuilder testing a use case arised where
- the available choices in configuration file for choosing a machine are incomplete
- putting every possible machine choice into that configuration is undesirable/not possible
- autobuilder code can write a machine selection into the bitbake config
after the fact.
So this --skip-selection option is intended for advanced users that know what they're doing
and is generally not recommended as it requires manually tweaking the bitbake config to
make it usable.
(Bitbake rev: 8cb2372bdad381179969d2ecbba7decaf03a7c5f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using sstate mirror places much higher requirements on both network robustness
and network bandwidth than just fetching source code. When the network doesn't meet
those, the user experience can be very frustrating as errors can be cryptic and
intermittent, or bitbake would just seemingly do nothing for a long time.
Let's make sstate an opt-in, and provide a caution for using it. When it does
work, it works wonderfully and does accelerate builds significantly.
(Bitbake rev: fe88a8e9cd5ccbc26508cf524a2f71a06d3df03a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is common practice to put the default choice in upper case for
yes/no interactive prompts, so that when people just hit enter, they
know what they are getting. An example that linux users are probably
familiar with is "sensors-detect" from the "lm-sensors" package.
Unify all the prompts to be the same and indicate that the default
answer from hitting enter is a no with an upper case N. No functional
changes.
(Bitbake rev: 7d6225722e21b116ae164fbaae2a918534a5107b)
Signed-off-by: Paul Gortmaker <paulg@kernel.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This implement the ability to use "{THISDIR}/my-layer" in the
"bb-layers" list. "{THISDIR}" is remplaced by the directory containing
the configuration file.
In small projects, we try to keep the setup a simple as possible: a
single git repo containing both the build confguration (e.g.
a bitbake-setup configuration file) and the meta layer with project
recipes/machine/distro.
This change allows this kind of setup:
├── meta-my-project/ # the project layer
└── my-project.conf.json # the bb-setup configuration file
by writing, in my-project.conf.json:
"bitbake-setup": {
"configurations": [{
"bb-layers": [
"{THISDIR}/meta-my-project"
Note: in this case meta-my-project is not present as a "source", so, not
handled by bb-setup update/status. It is expected of the user to handle
this on their own (is our case, a simple git workflow).
(Bitbake rev: b3153be29de8b8570b0c184369bd41f4c646cf92)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake-setup deduces top directory from BBPATH, which, if set, interferes with
the tests' own setup.
(Bitbake rev: e974d42eb5229f755e14b46a00ad06b23b53e143)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes maintaining and extending them easier.
(Bitbake rev: 16dc8e3dad7dde7e7651cce13549e61574cafba1)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Being minimalist, dash does not support the (non-POSIX) feature of
passing an argument while sourcing a script. Like in
. <some path>/oe-init-build-env <build dir>
With dash, one must use:
set <build dir> # puts <build dir> in $1
cd <some path>
. ./oe-init-build-env # can only be called from its directory in dash
To do this:
* Instead of a symlink to oe-init-build-env, keep a symlink to the
directory containing it (called "oe-init-build-env-dir")
* Generate a init-build-env script that dash can source using the above
snippet.
(Bitbake rev: 442b41c7949e1522212b66b16811f6b64b089b23)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"." is in POSIX standard[0], whereas "source" is only supported in more
feature-full shells (bash, zsh, ...)
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot
(Bitbake rev: 22c5fe7b2de74841e86d28a81143bd1a717518d9)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Particularly:
- ensure global settings command line argument is always expanded to
full path
- ensure any errors that happen when loading settings are reported
at that point, otherwise we get an empty dictionary and cryptic
key errors later
(Bitbake rev: 578afa2f05dfa6727952365918df703875070f64)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously bitbake-setup was checking out 'detached commits' using
fetcher's nobranch feature, as that is the only option when only a revision is in the config.
Branches are optional, but beneficial, as
- checkout directory will be on a branch, making it easier for users
to understand where they are if they need to make changes (also
bitbake will print branch information instead of saying 'HEAD:sha').
- supply chain security! Enforcing a branch means any specified revision
has to be on it, and no one can sneak in (accidentally or deliberately!)
some dangling commit, or something from their private branch in the same repo.
(Bitbake rev: 45ed9b9faebdaa8cb7cc8dd2a6d51ec8eea06e73)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the directory already exists but hasn't been setup, the current test
can fail so improve it.
(Bitbake rev: dac27bd5acbde1807b9637f809fd0ee5bf424286)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch the url to be the default internal registry rather than a private
repo which was intended for testing.
(Bitbake rev: e031b75b5b92552d812d2305a35ce90eb6c68b78)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than forcing every user to have to access a separate repository
for data for some key defaults, add those for nodistro and poky. This
gives us some commonly used setups and also something to test against too.
We will need to come up with a criteria for adding these, most likely based
on community usage/demand with the OE TSC governing that policy.
(Bitbake rev: 562de93d5b0e7cf0a9a43714d0563e5bcf6e9931)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is useful for bitbake-setup to support local paths without access through
the fetcher so that internal data to the bitbake repository can be used as
a default.
(Bitbake rev: ec82a6d402a0bec5704310c66c6f4206c75e4fc9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This basically calls install-buildtools from oe-core/poky, but
it ensures via command line parameters that the installation
location is stable and the downloads are preserved for reproducibility:
$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
======
Buildtools archive is downloaded into /home/alex/bitbake-builds/yocto-master-testing/buildtools-downloads/20250319141333 and its content installed into /home/alex/bitbake-builds/yocto-master-testing/buildtools
... (output from install-buildtools script)
======
It also detects when buildtools are already installed, and will direct
users what to do:
======
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
Buildtools are already installed in /home/alex/bitbake-builds/yocto-master-testing/buildtools.
If you wish to use them, you need to source the the environment setup script e.g.
$ . /home/alex/bitbake-builds/yocto-master-testing/buildtools/environment-setup-x86_64-pokysdk-linux
You can also re-run bitbake-setup install-buildtools with --force option to force a reinstallation
======
This commits includes fixes by Gyorgy Sarvari <skandigraun@gmail.com>
https://github.com/kanavin/bitbake/pull/2
(Bitbake rev: 3fe3096847046110c72b23fce37fb4a459b1d748)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run like this:
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-selftest -v bb.tests.setup
test_setup (bb.tests.setup.BitbakeSetupTest.test_setup) ... ok
----------------------------------------------------------------------
Ran 1 test in 9.223s
OK
The test does a basic run-through of init, then status/update
on an unchanged configuration, then status/update on a
configuration changed via new commits to the test layer,
then status/update on configuration changed via the top
level json config file.
Note that nothing whatsoever is fetched from the network;
the test relies entirely on synthetic data contained inside
itself, including minimal stubs for oe-setup-build and
bitbake-config-build. This data is used to create temporary
git repositories then clone them via local filesystem URIs.
Later on this can be supplemented by an oe-selftest that
tests bitbake-setup against real config files in the
official configuration repository and real layers,
templates and fragments.
(Bitbake rev: e3aa3eb46bd3196fa5415fa36e3737636fd6a1c0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Preamble
========
The latest iteration of this patchset is available at
https://github.com/kanavin/bitbake
I recommend taking the patches from there to ensure that
you are not trying out outdated code.
For the rationale and design guidelines please see this message:
https://lists.openembedded.org/g/openembedded-architecture/message/1913
Left out for now but will be done later:
- official configuration repository
- documentation
Amble *scratch* HOWTO
=====================
1. If you don't know where to start, run 'bitbake-setup init'.
Bitbake-setup will ask a few questions about available configuration choices and set up a build.
Note: 'init' sub-command can also take a path or a URL with a configuration file directly.
You can see how those files look like here:
https://github.com/kanavin/bitbake-setup-configurations
2. You can then source the bitbake environment and run bitbake to perform builds as usual:
$ . /home/alex/bitbake-builds/yocto-master-options-poky-distro_poky-machine_qemux86-64/build/init-build-env
Also, subsequent status/update commands will not require a separate --build-dir argument telling
bitbake-setup where the build is.
3. To check if the build configuration needs to be updated, run:
===
$ bin/bitbake-setup status
...
Configuration in /home/alex/bitbake-builds/poky-alex/ has not changed.
===
If the configuration has changed, you will see the difference as a diff.
...
- "rev": "akanavin/sstate-for-all"
+ "rev": "akanavin/bitbake-setup-testing"
...
If the configuration has not changed, but layer revisions referred to it have (for example
if the configuration specifies a tip of a branch), you will see that too:
===
...
Layer repository git://git.yoctoproject.org/poky-contrib checked out into /home/alex/builds/poky-alex/layers/poky updated revision akanavin/sstate-for-all from 6b842ba55f996b27c900e3de78ceac8cb3b1c492 to aeb73e29379fe6007a8adc8d94c1ac18a93e68de
===
4. If the configuration has changed, you can bring it in sync with:
$ bin/bitbake-setup update
Note that it will also rename/preserve the existing build/conf directory, and print changes
in bitbake configuration (diff of content of build/conf/) if that has changed. I can't
at the moment think of anything more clever that is also not much more brittle or complex
to implement, but open to suggestions.
Terminology
===========
- 'top directory' means the place under which bitbake-setup reads and
writes everything. bitbake-setup makes a promise to not touch anything outside of
that, unless otherwise directed to by entries in settings (currently
there is one such setting for fetcher downloads for layers and config
registries). Top directory can be selected by an environment variable, a command line option,
or otherwise assumed to be ~/bitbake-builds/. If BBPATH is in environment
(e.g. we are in a bitbake environment), then the top directory is
deduced from that and doesn't need to be specified by hand.
- 'settings' means bitbake-setup operational parameters that are
global to all builds under a top directory. E.g. the location of
configuration registry, or where the bitbake fetcher should place the
downloads (DL_DIR setting). Settings are stored in a .conf file in ini
format just under the top directory.
- 'build' means a tree structure set up by 'bitbake-setup init',
consisting of, at least, a layers checkout, and a bitbake
build. It maps 1:1 to the json data it was constructed from, which is
called 'build configuration'. Build configurations are constructed from
generic configurations that may involve making one or more choices
about available options in them. Generic configurations are files, URLs
or are obtained from git repositories called 'config
registries', in which case they can be listed with 'bitbake-setup
list'. There can be multiple 'builds' under a top directory. Here are
two example generic configurations that showcase this:
https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-options.conf.jsonhttps://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-nested-configs.conf.json
- 'bitbake-setup status' will tell if a build is in sync with
the generic configuration it was made from. 'bitbake-setup update' will bring a build
in sync with a configuration if needed.
- 'bitbake build' means a particular sub-tree inside a build that
bitbake itself operates on, e.g. what is set in BBPATH/BUILDDIR
by oe-init-build-env. conf/* in that tree is 'bitbake configuration'.
Bitbake configurations are constructed from templates and fragments,
with existing mechanisms provided by oe-core. The configuration file
format is specified such that other mechanisms to set up a
bitbake build can be added; there was a mention of ability to specify
local.conf content and a set of layers directly in a configuration. I
think that scales poorly compared to templates and fragments, but I
made sure alternative ways to configure a bitbake build are possible
to add in the future :)
- 'source override' is a json file that can be used to modify revisions
and origins of layers that need to be checkout into a build (e.g.
when master branches need to be changed to master-next for purposes
of testing). Such a file is specified with a command-line option to 'init'
and an example can be seen here:
https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-next.override.json
This commit includes fixes by
Ryan Eatmon <reatmon@ti.com> https://github.com/kanavin/bitbake/pull/1
Gyorgy Sarvari <skandigraun@gmail.com> https://github.com/kanavin/bitbake/pull/2
Johannes Schneider <johannes.schneider@leica-geosystems.com> https://github.com/kanavin/bitbake/pull/3https://github.com/kanavin/bitbake/pull/5
(Bitbake rev: b96154aeb1fc89184ac245e0d68e6e726fe80c04)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lastpids has not been used for almost 10 years.
* There is no longer any need to use running_pids to keep track of the
order the pids in running_tasks were added as dicts are guaranteed to
remember the insertion order since Python 3.7.
(Bitbake rev: 562b5bf0be2883144391e7030a9dce6a233802ac)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having multiple builtin config fragments for the same variable
(eg OE_FRAGMENTS = "... machine/A ... machine/B") is not supported.
Warn the user to make them fix this but continue with the normal
variable evaluation : the last affectation "wins".
Added warning looks like:
WARNING: Multiple builtin fragments are enabled for machine via variable OE_FRAGMENTS: machine/qemux86-64 machine/test machine/qemux86-64. This likely points to a mis-configuration in the metadata, as only one of them should be set. The build will use the last value.
(Bitbake rev: 1c12aa23f6678dc289fc0e0d8b4dad311bd39c35)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot 2025.10rc2 based firmware from meta-ts
https://gitlab.com/Linaro/trustedsubstrate/meta-ts
triggers some non-fatal errors from various drivers.
Ignore them for now since all other oeqa runtime tests pass
since in genericarm64 we don't build this firmware.
(From meta-yocto rev: fe65e142d0d9ba0e51ff9175ffa82e902f982a20)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With firmware files and more kernel modules the size
limit is hit again. Increase by 60Mb.
(From meta-yocto rev: 4348f496cf4950cf665d7c56643718b5238e96bf)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Copied from meta-qcom
recipes-bsp/packagegroups/packagegroup-rb3gen2.bb
Sadly does not fully resolve kernel error messages
from WiFi firmware files.
(From meta-yocto rev: 6fd803cd96746cbf3ae625d0fadbb176ce1b2919)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The firmware file is not available from linux-firmware package
so it may be that another file name is used instead. Thus
this non-fatal error can be ignored for now.
(From meta-yocto rev: 2d442f338cbd4a681388c093899a5709b7881d96)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
by default. Fixes parselogs oeqa runtime test failures:
https://ledge.validation.linaro.org/scheduler/job/121516
Central error: brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
...
Central error: brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.bin failed with error -2
(From meta-yocto rev: dce46431683b5172327770972166c79e4c60cc2d)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot 2025.10rc2 based firmware from meta-ts
https://gitlab.com/Linaro/trustedsubstrate/meta-ts
triggers some non-fatal errors from various drivers.
Ignore them for now since all other oeqa runtime tests pass
since in genericarm64 we don't build this firmware.
(From meta-yocto rev: 0b15a104ea04acd79b87f7cf3da96f637dafdef4)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With u-boot 2024.04 based firmware the board firmware seems to
have one small issue which kernel complains about. The board
works well and passes other tests so ignore this for now.
(From meta-yocto rev: 56f33867249f79340f868cb90bc7e4c2a6a641d2)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot 2025.10rc2 based firmware from meta-ts
https://gitlab.com/Linaro/trustedsubstrate/meta-ts
triggers some non-fatal errors from various drivers.
Ignore them for now since all other oeqa runtime tests pass
since in genericarm64 we don't build this firmware.
(From meta-yocto rev: 6fc9c8e2a8b23877c2cd2bac43d37dcaf5b6c8ef)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rockchip rk3399 based rockpi4b with u-boot 2025.10rc2 based firmware
from meta-ts https://gitlab.com/Linaro/trustedsubstrate/meta-ts
triggers some non-fatal errors from various drivers.
Ignore them for now since all other oeqa runtime tests pass
since in genericarm64 we don't build this firmware.
https://ledge.validation.linaro.org/scheduler/job/119422
(From meta-yocto rev: b91b6ca6827d489ecb21cb688403c2b1c76ccd52)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch to PACKAGECONFIG in order to make x264 options configurable.
Enable FFmpeg (by default) and OpenCL (if enabled by the distro). Pick
up the patch to fix building with the latest FFmpeg.
(From OE-Core rev: 4339bf44faa11bf5933f23ac5b0b6ecaa5a1afab)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
brings following fixes
* 450f52eec88f Bump version to 21.1.3.
* 05b5090e961f Port 5b4819e to release/21.x
* 2cb08dbb39b1 [compiler-rt][sanitizer] fix msghdr for musl (#136195)
* 6e687cbe0dd3 [SPARC] Prevent meta instructions from being inserted into delay slots (#161111)
* f8151a1d2c86 [clang] [Headers] Don't use unreserved names in avx10_2bf16intrin.h (#161824)
* 9ee4ac8a8359 [clang][SPARC] Pass 16-aligned structs with the correct alignment in CC (#155829)
* 220bac16a417 [Hexagon] Add opcode V6_vS32Ub_npred_ai for offset validity check (#161618)
* a867bd53e861 [clang][PAC] Don't try to diagnose use of pointer auth on dependent types #159505 (#159859)
* 41e817a1d1f4 release/21.x: [clang-format] Fix bugs in annotating arrows and square brackets (#160973)
* 559d966bcb54 [Mips] Fix atomic min/max generate mips4 instructions when compiling for mips2 (#159717)
* d1e2f8916128 [LLD] [COFF] Fix symbol names for import thunks (#160694)
* 0060034c6a0b [analyzer] Revert #115918, so empty base class optimization works again (#157480)
* 31e4363ba9c2 [NVPTX] Disable relative lookup tables (#159748)
* 74cb34a6f51a Bump version to 21.1.3
(From OE-Core rev: 4a590bdd8794c6873f9ff0dc6d988d62f5b2ca5c)
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>
Upgrade all Vulkan-related packages together in a single commit.
License-Update: glslang dropped SPIR-V remapper
(From OE-Core rev: 55c7566c33833a8f36cbf50a70cb1a1cf7aa96d5)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the definitions of MIRRORS and PREMIRRORS made by
test_yocto_source_mirror() are overwritten when run on the autobuilder:
* MIRRORS = "" is extended by mirrors.bbclass to its usual value.
* PREMIRRORS = "* dl.yp.org" is overwritten by the autobuilder.conf
config fragment to ""
Simplified variable history:
# $MIRRORS [4 operations]
# set .../contribution-yocto/builds/build-qemux86-64-st/conf/selftest.inc:3
# ""
# append .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/classes-global/mirrors.bbclass:57
# "${DEBIAN_MIRROR} ..."
MIRRORS=" http://deb.debian.org/debian/pool ..."
# $PREMIRRORS [4 operations]
# set .../contribution-yocto/builds/build-qemux86-64-st/conf/selftest.inc:18
# " bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n ..."
# set .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/conf/fragments/yocto-autobuilder/autobuilder.conf:6
# ""
# append .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/classes-global/mirrors.bbclass:84
# "git://sourceware.org/git/glibc.git https://downloads.yoctoproject.org/mirror/sources/ ..."
PREMIRRORS=" git://sourceware.org/git/glibc.git https://downloads.yoctoproject.org/mirror/sources/ ..."
Despite this unexpected configuration, the test passes because after
failing to find a PREMIRROR (empty), failing to download the normal
SRC_URI (because of BB_ALLOWED_NETWORKS), the fetcher tries the MIRRORS
which have by default download.yoctoproject.org. For example, on a
failed meta-oe-mirror test[0], we can see a lot of warnings:
"stdio: WARNING: ... do_fetch: Failed to fetch URL https://... attempting MIRRORS if available"
By using the ":forcevariable" override, test_yocto_source_mirror() makes
sure the correct value is set for MIRRORS and PREMIRRORS (whatever is
the configuration).
Simplified variable history (after the fix):
# $MIRRORS [4 operations]
# append .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/classes-global/mirrors.bbclass:57
# "${DEBIAN_MIRROR} ..."
# append .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/classes-global/mirrors.bbclass:68
# "git://salsa.debian.org/.* ..."
# override[forcevariable]:set .../contribution-yocto/builds/build-qemux86-64-st/conf/selftest.inc:3
# ""
MIRRORS=""
# $PREMIRRORS [4 operations]
# set .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/conf/fragments/yocto-autobuilder/autobuilder.conf:6
# ""
# append .../contribution-yocto/builds/build-qemux86-64-st/../../layers/poky/meta/classes-global/mirrors.bbclass:84
# "git://sourceware.org/git/glibc.git ..."
# override[forcevariable]:set .../contribution-yocto/builds/build-qemux86-64-st/conf/selftest.inc:18
# " bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ ..."
# pre-expansion value:
# " bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ ..."
PREMIRRORS=" bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ ..."
[0]: https://autobuilder.yoctoproject.org/valkyrie/#/builders/82/builds/470/steps/17/logs/warnings
Fixes [YOCTO #15993]
(From OE-Core rev: ab810d1239d4db0bc0f23db31c70cc9c6e59357e)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sort the lists of VUKAN_DRIVERS, GALLIUMDRIVERS and driver-related
PACAKGECONFIG entries, making it easier to add new drivers or to find
out the correct dependencies for the driver.
(From OE-Core rev: 64108679ada885b74fcc6ac49f9e5e983f34e663)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Historically mesa recipe had separate variables for drivers that
depended on gallium-llvm PACKAGECONFIG. Since that time we started
listing other dependencies explicitly (e.g. libclc). Drop the
intermediate variables and make the dependency on gallium-llvm more
explicit.
(From OE-Core rev: d3ce0b8a9964d2a0afe98701ee4d51b2dbd8d64e)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Asahi drivers depend on the clc to be available, but not on the
RustiCL. Make it possible to build asahi drivers with opencl disabled.
(From OE-Core rev: c869128ba34d1c9c9952206fb6814e6fdbd39bef)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the commits 448f4a84cb22 ("llvm: add recipe for just the LLVM
libraries") and d76dc362c8e1 ("clang: use llvm recipe") the 'llvm'
dependency inside mesa.inc does no longer pull in the clang libraries,
failing RustiCL build as it can not find Clang libaries.
Add direct dependency on the clang in order to fulfill build-time deps.
Fixes: d76dc362c8e1 ("clang: use llvm recipe")
(From OE-Core rev: b8fa4a0ac33638b599ee169db11b5e77b2483148)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pick patch per link in NVD report.
(From OE-Core rev: 363961f74e3a8df3d1b97ce33855b8b40f6da497)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pick patch per link in NVD report.
(From OE-Core rev: 4c72e3bcf1f7898e69d5b0b0d490e550bb96bc0e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE: CVE-2025-11081
Trying to dump .sframe in a PE file results in a segfault accessing
elf_section_data.
* objdump (dump_sframe_section, dump_dwarf_section): Don't access
elf_section_type without first checking the file is ELF.
PR 33406 SEGV in dump_dwarf_section
[https://sourceware.org/bugzilla/show_bug.cgi?id=33406]
Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f87a66db645caf8cc0e6fc87b0c28c78a38af59b]
(From OE-Core rev: d1eb65d2e9365f6bd2acf450496d3bfeda6aedc1)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building cargo-c with DEBUG mode, QA checks fail due to
absolute paths from the build environment (TMPDIR) being embedded into
the debug symbols/binaries. This causes issues such as:
ERROR: do_package_qa: File /usr/bin/.debug/cargo-capi contains reference to TMPDIR [buildpaths]
ERROR: do_package_qa: File /usr/bin/.debug/cargo-cinstall contains reference to TMPDIR [buildpaths]
ERROR: do_package_qa: File /usr/bin/.debug/cargo-cbuild contains reference to TMPDIR [buildpaths]
ERROR: do_package_qa: File /usr/bin/.debug/cargo-ctest contains reference to TMPDIR [buildpaths]
To fix this, pass an additional -ffile-prefix-map option to DEBUG_PREFIX_MAP to
ensure that paths under `${CARGO_HOME}` are remapped to `${TARGET_DBGSRC_DIR}`.
This ensures debug info is reproducible and does not leak host-specific paths.
(From OE-Core rev: 3239961e35434592c06ec2cae2885ab464d35744)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Each UBOOT_CONFIG entry is run in a different directory under ${B} so
that the files can be generated, compiled, and installed differently
from each other. Currently that unique directory name was just the
defconfig used for each UBOOT_CONFIG.
One potential conflict arises when you want build the same defconfig
twice, but pass in different make options. Then we get directory
collision. Simple fix is to include both the defconfig name and the
UBOOT_CONFIG type in the directory name.
This change has the potential to be backwards breaking if a layer is
using the UBOOT_CONFIG flow and overriding/appending any of the do_*
shell functions. Each of those will either need to change to using:
${B}/${config} -> ${B}/${config}-${type}
or for append functions they can use the new variable in the parent
function:
${B}/${config} -> ${B}/${builddir}
(From OE-Core rev: 22e96b32b0be02ec0971c9334d4b1df7c9ef8d84)
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In gawk-5.2, a feature that allows gawk to preserve memory between runs:
https://www.gnu.org/software/gawk/manual/html_node/Persistent-Memory.html
was added. The files that implement this, support/pma.[ch], are licensed
under the AGPL3 which some entities perfer to avoid. Force people to knowingly
opt into using this feature and license using:
PACKAGECONFIG:append:pn-gawk = " pma-if-64bit"
where pma is an abbreviation for persistent memory allocator and the
"-if-64bit" suffix is a indicator to users that the feature only works
for 64 bit targets. Also add AGPL to LICENSE and LICENSE:${PN}, when using pma.
Correct the license to be AGPL-3.0-or-later. There hasn't been a change in
the license terms, at least for main.c, haven't changed significantly in
the last 15 years:
License-Update: Reflects conditional AGPL use and more as described above.
Testing requires a non-root account and following the example in the link above:
$ truncate -s <size> data.pma
$ chmod 0600 data.pma
$ GAWK_PERSIST_FILE=data.pma gawk 'BEGIN { print ++i }'
1
$ GAWK_PERSIST_FILE=data.pma gawk 'BEGIN { print ++i }'
2
$ GAWK_PERSIST_FILE=data.pma gawk 'BEGIN { print ++i }'
3
This works on qemu[x86-|arm|riscv]64 but not on qemu[arm|x86] where the
--enable-pma is ignored because there is a requirement and build-time test
for 8 byte void pointers in m4/pma.m4:
if test "$SKIP_PERSIST_MALLOC" = no && test $ac_cv_sizeof_void_p -eq 8
Finally, remove an old comment about GPLv2, GPLv3 versions of gawk
since this is no longer important as the GPLv2 version is not maintained.
(From OE-Core rev: d7b6887dfbe2817ceb03d44a59210f65bbb25390)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade to latest 1.25.x release [1]:
$ git --no-pager log --oneline go1.25.1..go1.25.2
bed6c81c2d (tag: go1.25.2) [release-branch.go1.25] go1.25.2
2612dcfd3c [release-branch.go1.25] archive/tar: set a limit on the size of GNU sparse file 1.0 regions
90f72bd500 [release-branch.go1.25] encoding/pem: make Decode complexity linear
e0f655bf3f [release-branch.go1.25] encoding/asn1: prevent memory exhaustion when parsing using internal/saferio
100c5a6680 [release-branch.go1.25] net/http: add httpcookiemaxnum GODEBUG option to limit number of cookies parsed
f0c69db15a [release-branch.go1.25] crypto/x509: improve domain name verification
9fd3ac8a10 [release-branch.go1.25] net/url: enforce stricter parsing of bracketed IPv6 hostnames
5d7a787aa2 [release-branch.go1.25] net/textproto: avoid quadratic complexity in Reader.ReadResponse
930ce220d0 [release-branch.go1.25] crypto/x509: mitigate DoS vector when intermediate certificate contains DSA public key
6a057327cf [release-branch.go1.25] net/mail: avoid quadratic behavior in mail address parsing
66f6feaa53 [release-branch.go1.25] spec: revert "update spec date to match release date"
d6f2741248 [release-branch.go1.25] spec: update spec date to match release date
28ac8d2104 [release-branch.go1.25] net/http: avoid connCount underflow race
06993c7721 [release-branch.go1.25] context: don't return a non-nil from Err before Done is closed
0b53e410f8 [release-branch.go1.25] debug/pe: permit symbols with no name
7735dc90ed [release-branch.go1.25] cmd/compile: don't rely on loop info when there are irreducible loops
205d086595 [release-branch.go1.25] crypto/tls: quote protocols in ALPN error message
16fdaac4b1 [release-branch.go1.25] sync/atomic: correct Uintptr.Or return doc
f3dc4aac0b [release-branch.go1.25] runtime: initialise debug settings much earlier in startup process
79c3081b4b [release-branch.go1.25] internal/poll: don't call Seek for overlapped Windows handles
b816c79658 [release-branch.go1.25] lib/fips140: re-seal v1.0.0
90de3b3399 [release-branch.go1.25] crypto/internal/fips140: remove key import PCTs, make keygen PCTs fatal
bec452a3a2 [release-branch.go1.25] crypto/internal/fips140: update frozen module version to "v1.0.0"
57bd28ab7f [release-branch.go1.25] crypto/internal/fips140/ecdsa: make TestingOnlyNewDRBG generic
f75bcffa4a [release-branch.go1.25] os: set full name for Roots created with Root.OpenRoot
7d570090a9 [release-branch.go1.25] os: fix Root.MkdirAll to handle race of directory creation
be61132165 [release-branch.go1.25] cmd/compile: export to DWARF types only referenced through interfaces
a86792b169 [release-branch.go1.25] net: skip TestIPv4WriteMsgUDPAddrPort on plan9
879e3cb5f7 [release-branch.go1.25] runtime: lock mheap_.speciallock when allocating synctest specials
Fixes CVE-2025-61725, CVE-2025-58187, CVE-2025-58189, CVE-2025-61723,
CVE-2025-47912, CVE-2025-58185, CVE-2025-58186, CVE-2025-58188,
CVE-2025-58183 and CVE-2025-61724 [2].
[1] https://github.com/golang/go/compare/go1.25.1...go1.25.2
[2] https://groups.google.com/g/golang-announce/c/4Emdl2iQ_bI
(From OE-Core rev: b46e8fdfc23a575ee8c69c136c7815e366a7e904)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
