We use the kernel.org mirrors for a number of projects: obviously the
kernel, but also the GNU tarballs are fetched from there too.
However, mirrors.kernel.org does not have any geo-proximity DNS magic
and will always resolve to the primary server on in west coast USA,
which is far from ideal if you're not near there.
Switch the mirror URLs to mirrors.edge.kernel.org, which does actually
resolve to a closer server.
(From OE-Core rev: 63d586cd6499ef2a8d311223fa0e1ed9d071dd0e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Release notes are available at [0].
[0]: https://cmake.org/cmake/help/v4.1/release/4.1.html#id2
(From OE-Core rev: 53be4345591dd874cdf339081dffc4095fdb41da)
Signed-off-by: Moritz Haase <Moritz.Haase@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the linux-firmware packate to the latest release. Add firmware
packages for Intel Sensors Hub on Dell and HP machines and also several
new Qualcomm firmware packages
License-Update: new and updated firmware
(From OE-Core rev: 5df2e6ddeef250357ccab00b62e20102f3999f53)
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 linux-firmware now being an empty package there is no need in
the catch-all ${PN}-ath*k-misc packages since developers will have to
package all firmware separately. Drop useless packages now.
(From OE-Core rev: 945c91f01e829fec82e62180f14ab1edceb24e15)
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>
This commit mainly changes the way that error messages are printed when
sanity checking for the version numbers of gcc, patch, git, make and
tar. It affects the following functions:
check_patch_version(),
check_make_version(),
check_gcc_version(),
check_tar_version(),
check_git_version()
Before this commit, the minimum version number and the error string
were hard-coded string literals which the programmer had to maintain
manually and independently. With this change, the version is defined
once in each function and then used both for checking and for error
printing.
Additionally, the affected error messages have been made to spill
over multiple lines for better source code readability.
Link to the relevant discussion:
https://lists.openembedded.org/g/openembedded-core/topic/115491380#msg224131
This change has been tested by changing the version string and making
sure that the test fails and the proper minimum version is reported
in the error message.
Suggested-By: Yoann Congal <yoann.congal@smile.fr>
(From OE-Core rev: 27a4ce7b34946200e35adfab1ace512a531fc560)
Signed-off-by: Andreas Stergiopoulos <andreas.stergiopoulos@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade to release 3.11:
- Update to Unicode 16.0.0, including significant changes to UTS46
processing. As a result of Unicode ending support for it,
transitional processing no longer has an effect and returns the
same result.
- Add support for Python 3.14, lowest supported version is
Python 3.8.
- Various updates to packaging, including PEP 740 support.
License-Update: Update years
(From OE-Core rev: 8dcbbad9ad5f66cc39f1fc88517267c2e7ccb951)
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New Vulkan CTS 1.4.4 started requiring glx.pc pkg-config file. Apply a
patch adding one in order to let VK CTS and other programs find Mesa GLX
implementation.
(From OE-Core rev: 15c02892d9c00de3c9879d5ffcecfeba6f5ee1ab)
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>
Adds variables to set the name of the weston user (defaulting to
"weston") and the home directory (defaulting to "/home/weston"). This
allows users to easily change which user the compositor runs as.
(From OE-Core rev: 079cf188adae1c7de3971a64df8cb04d5f47be4e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This musl-related fix to TargetLibraryInfo has been obsolete since LLVM
version 5.0 as it was fixed in a different way:
commit d21529fa0df71327aab230786e345b2071f4ac4f
Author: David L. Jones <dlj@google.com>
Date: Mon Jan 23 23:16:46 2017 +0000
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
(From OE-Core rev: 426504625c67dd8235a72a1128452c1592462ff3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove perlnative inherit, this recipe does not depend on non-standard
perl (or any perl, in fact).
Remove python3native inherit, this recipe does not depend on non-standard
Python modules. python3-native will still be pulled into the sysroot via
python3targetconfig however.
Remove PACKAGECONFIG:remove:powerpc, as powerpc is explicitly marked as
not compatible later in the recipe.
Remove LLVM_ENABLE_PER_TARGET_RUNTIME_DIR, this is only used during
monolithic builds of llvm.
Remove OPENMP_STANDALONE_BUILD, this is automatically detected when
building.
Remove CMAKE_POSITION_INDEPENDENT_CODE, this is the default value.
Remove all _TOOL, these are not used.
(From OE-Core rev: 87bb7e18e8a37803ec7c96c640347ac515d073d2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of building libperf.a, we should run install_headers as with the other
libraries. Hopefully this resolves the remaining race issue around headers.
(From OE-Core rev: 647589fab1fb73a985cbba4c1bec2004831508ca)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
vte 0.82+ has started to package fmt as a subproject if this is not found
on system, the bundled version however, does not work with clang on
32bit machines, since it is 11.0 and there are fixes in newer version
needed to work with clang
Fixes
../sources/vte-0.82.1/subprojects/fmt/include/fmt/format.h:752:35: error: call to function 'free' that is neither visible in the template
(From OE-Core rev: 826c4a1339b8f8c354d55a5dad7aa7674b30dc2e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patchelf hasn't released since 2023 but does have fixes on its master branch. We've been
seeing segfaults on relocated qemu-img binaries from qemu-system-native in some cases
and using an updated patchelf does seem to avoid these.
The patches have all be applied upstream.
0e338941fc is 2/3 combined
License-Update: Change http -> https
[30da44915e]
[YOCTO #16003]
(From OE-Core rev: ec616d5ab1d3147a2634a0506111e88964da3fad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has been the default in poky's local.conf.sample since forever. It was missing
during the migrtion to bitbake-setup and that created a few failures. We've fixes most
of the places but found a new one in the performance tests.
Having these available is useful for debugging and doesn't really add much overhead
to the build.
We could push this over into the poky DISTRO however I've been wanting to
try and reconcile things where possible so putting this into defaultsetup feels
like the right choice to me. Distros can still override as they would the other
classes in INHERIT_DISTRO.
(From OE-Core rev: b297c9d6168e3906b581387f1d731ea95e17dd83)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit[1] in pseudo introduced the PSEUDO_INCLUDE_PATHS variable, however
the previous PSEUDO_IGNORE_PATHS variable is still present also. Add a clarifying
note about the order of precedence of the two.
[1]: https://git.yoctoproject.org/pseudo/commit/?id=2c43381180f9cfef4c0a8bb0c1658a86c3fcc876
(From yocto-docs rev: 8b85245490ae0b19a9c3880ec31e55b42e19d094)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
What we have is OCI = $(which $CONTAINERCMD) = /usr/bin/{docker,podman}.
So we never pass the current if conditions. Compare against the basename
of OCI to pass the checks.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 41fc95a0e06fec29cdd8c47f75093f0a6a2df8c0)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This behavior was removed in commit aea2d69d0533
("lib/bbconfigbuild/configfragments: disable the previous builtin
fragment when enabling a new one") in OE-Core.
(From yocto-docs rev: e420f0f90614b13fc92654219296182858ca17b9)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The references in this document do not work because references need to
be associated to a title. Change the bullet list into a section
separated document. This way we can cross-reference QA checks in other
parts of the documentation (it was previously failing when attempted).
The diff is a bit hard to digest, but there are no changes to content
except for:
- A fixed typo (inhert -> inherit)
- Indentation
(From yocto-docs rev: 93c30b8a430a981e8b89061c968a006a3e086353)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Leap 15.6 worked fine on my local builds, with Docker or Podman.
Ubuntu 23.04 got removed from the list of distros we test.
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 2e3d33f47dfba64a81767accb6a47cae842bd18e)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The script currently only installs the files necessary to build the
docs. Since we also have the essential packages listed it can be useful
to include them in the containers, at least to validate that these
successfully install.
Add an env variable for including these packages in the container. The
default is to not include these, so the current behavior is unchanged.
(From yocto-docs rev: 723e531ea442df96fd592635a2fbfba73e737886)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the lists of tests as found OE-Core as of commit 07747aa7390e
("piglit: rename virtual/opencl-icd to virtual/libopencl1").
Add a link to the test directory in case the list is update, users can
still browse through the code.
(From yocto-docs rev: c3783914d01d313a35e29e75e562eefba5e40df4)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The yocto-check-layer script should be run with the --machines arguments
to test the different machines present in a BSP layer. Mention it in the
documentation. The --dependency can also be used so also mention that.
[YOCTO #15974]
Cc: Mark Hatle <mark.hatle@kernel.crashing.org>
(From yocto-docs rev: 2cd7b5c83978819179b8a47e213b9812b97d5720)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test was written assuming poky was being used. Update
the revisions to match OE-Core instead.
(From OE-Core rev: 5965ae92c866817a0bab54d240b1d197da37df2a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without a specified ABI, rustc panics with the following error:
| thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/metadata.rs:394:21:
| No ABI specified for this PPC64 ELF target.
This issue was occuring because of the following Rust commit:
9c1180b623
As noted in the upstream changes:
If the flags do not correctly indicate the ABI,
linkers such as ld.lld assume that the ppc64 object files are always ELFv2,
which leads to broken binaries if ELFv1 is used for the object files.
Because of this, it is now required to explicitly specify the ABI for PPC64 targets
using one of the following:
"elfv1" => EF_PPC64_ABI_ELF_V1,
"elfv2" => EF_PPC64_ABI_ELF_V2,
If no ABI is specified, the Rust compiler will panic with the error:
No ABI specified for this PPC64 ELF target
To address this:
- Set 'elfv2' for powerpc64le (little-endian), which mandates ELFv2 ABI.
- Set 'elfv1' for powerpc64 (big-endian), which defaults to ELFv1 ABI.
(From OE-Core rev: 6cee30b7941c22eef52011b6bac0d3c0d7944abe)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LLD is strict about versioned symbols unlike BFD linker, it flags
undefined ones, Allow undefined symbols like BFD linker
Fixes
| riscv64-yoe-linux-ld.lld: error: version script assignment of 'global' to symbol 'pam_sm_acct_mgmt' failed: symbol not defined
| riscv64-yoe-linux-ld.lld: error: version script assignment of 'global' to symbol 'pam_sm_chauthtok' failed: symbol not defined
| riscv64-yoe-linux-ld.lld: error: version script assignment of 'global' to symbol 'pam_sm_close_session' failed: symbol not defined
| riscv64-yoe-linux-ld.lld: error: version script assignment of 'global' to symbol 'pam_sm_open_session' failed: symbol not defined
| riscv64-yoe-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation)
(From OE-Core rev: a53fddbb99dc746439b5b2adfb7f747ba25a856f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the sub-command 'settings' would take any number of
arguments and then silently do nothing if the number wasn't three.
The help text was also not clear about this, marking the positionals
separately as optional:
usage: bitbake-setup settings [-h] [--global] [--unset UNSET UNSET] [-l] [section] [key] [value]
The '--unset SECTION SETTING' also did not integrate too well, as it
had its own positional arguments for section+setting.
For a bit more consistency and a explorable help, a sub-subparser is
added, that provides the commands:
bitbake-setup settings list
bitbake-setup settings set foo bar baz
bitbake-setup settings unset foo bar
with a '--global' that is added from a stand-alone parent parser, so
that it shows up in all sub-command help texts.
The new help text now reads:
usage: bitbake-setup settings [-h] [--global] {list,set,unset} ...
and the respective sub commands:
usage: bitbake-setup settings list [-h] [--global]
usage: bitbake-setup settings set [-h] [--global] <section> <setting> <value>
usage: bitbake-setup settings unset [-h] [--global] <section> <setting>
(Bitbake rev: 8b582ef8dd0cef0192d4c0104bcd9b5d642d132c)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a metavar to the argparse options to have a self-descriptive help text.
Otherwise argpase defaults to use the argument name in all-uppercase.
Before:
usage: bitbake-setup [-h] [-d] [-q] [--color COLOR] [--no-network] [--global-settings GLOBAL_SETTINGS] [--setting SETTING SETTING SETTING]
{list,init,status,update,install-buildtools,settings} ...
After:
usage: bitbake-setup [-h] [-d] [-q] [--color COLOR] [--no-network] [--global-settings PATH] [--setting SECTION SETTING VALUE]
{list,init,status,update,install-buildtools,settings} ...
(Bitbake rev: 83cecc9356a0684f90249d527fe372298ae92719)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To align the storage destination with the internally used variable
name. This makes room for having another option use 'args.setting'
(Bitbake rev: 14d8535309abc78ee30cfdb51bba2e00b474f443)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In cases where the first call to 'init' failed or was aborted before
creating the 'build/init-build-env' has been created, a user can get
stuck: a second call to init aborts, suggesting 'status' or 'update'
but these to refuse because the --build-dir is not valid.
Guide the user by adding a suggestion to start over from scratch.
(Bitbake rev: 11b2740c3e19e0c6680229c6bbce3691c73746a8)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After some further feedback, additional changes are made:
1. 'setting' command is renamed to 'settings' to better reflect
that it is an interface to various ways of managing settings.
2. This command now has a -l/--list option to list all settings
with their values (same as 'git config -l').
3. A new level of settings (built-in defaults) is added,
and used as a last resort after command line options, top dir
settings file and global settings file.
4. This means bitbake-setup does not have to write and use a
global settings file, and it no longer does so when initializing
a build, avoiding default 'pollution' of ~/.config/bitbake-setup/
which can be problematic or unwelcome.
A global settings file is still created if a setting is explicitly
requested to be placed into it.
5. 'install-global-settins' is removed as the use case for it
(tweak default settings before using them to initialize a build)
can be achieved by setting the settings individually.
5. Similarly, a top dir settings file is no longer created by default
and only appears if a setting needs to be written into it.
6. Default dl-dir is again created inside a top directory and not
in ~/.cache/ to make default builds fully contained in the top
directory (which was also asked about).
(Bitbake rev: 664f8ec48d42d2ddc5f234c4f7d590fa597f489a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the outcome of various discussions, suggestions and pull
requests on github.
What has specifically changed?
1. The sources for the settings are no longer separated, but are stacked and given priorities,
from highest to lowest:
a. '--setting section key value' on the command line
b. a settings file in the top directory
c. a global settings file in ~/.config/bitbake-setup/ (or in a file pointed to by --global-settings)
Any setting can be in any of these three locations (other than top dir name and prefix which do not
make sense in the settings file in the top directory).
2. A global settings file must contain all of the needed settings, while a settings file
in the top directory can be empty (and this is how they are written out if they do not exist).
Specifically, both dl-dir and registry settings have been relocated to the global file,
and dl-dir defaults to ~/.cache/bitbake-setup/downloads, rather than somewhere in top dir.
3. The file name for both global and top dir settings is now 'settings.conf'.
4. --top-dir-prefix and --top-dir-name options have been removed and superseded by
a generic, universal --setting option.
5. 'install-settings' command has been removed, as it is no longer does anything useful,
and is superseded by the 'setting' command (see below).
'install-global-settings' has been retained, to be able to have a set of global defaults
that can be changed without initializing a build.
6. 'change-setting', 'change-global-setting' and 'install-settings' have all been replaced
by a single 'setting' command that mimics 'git config' in its parameters:
a. Changing a setting: bitbake-setup setting [--global] default dl-dir /path/to/downloads
b. Removing a setting: bitbake-setup setting [--global] --unset default dl-dir
(Bitbake rev: 713e7f213c6d4a620be9ce34d5f4396af48e1d69)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test configuration to cover the 'bb-env-passthrough-additions'
conf.json key, and add it to the test routine.
(Bitbake rev: 24f12b68692f9ebb5d3813bc3b1771e43298f640)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
