Kernels that do not use modules do not have the Modules.symvers file,
which causes the previous one-liner to fail. Invert the logic so that
the absence of the Modules.symvers is a passing situation but we still
get failure checking on the install operation.
(From OE-Core rev: 6fff6ce35864cfef70ffd10db3b7d5f090dd3f62)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 856c916ffbf3438d8cf5d8bed344473bde03b56e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.
This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.
This patch resolves the issue by comparing the variables before they are
modified.
(From OE-Core rev: 76ca96ebde8c318e32d4bf65714a6241965b0b8f)
Signed-off-by: Staffan Rydén <staffan.ryden@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This was not well researched or explained, and obscures a problem elsewhere:
if dnf leaves lock files around, the problem should be fixed at the source,
and not in an after-the-fact function.
(From OE-Core rev: d38e40661acfbd84197a7731f0dd02d16fba7c59)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 49bad18012a4079f0dbfe6c541a46ec508940f28)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
opkg-native hasn't provided update-alternatives since 2014[1] so this is
the wrong dependency, and image.bbclass depends on the virtual provider
virtual/update-alternatives-native already.
[1] oe-core 1e2c38ce13f8e4b25d8656d237343380cbc970aa
(From OE-Core rev: 49be8045a6595cb98413519d2e65e94345f026c1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 51004376be9a6b9a4c38585d14d2516d90138319)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Default search in meson would grok /usr/bin for llvm-config and if found
will use it, which might add wrong paths into cflags/ldflags, since we
depend on llvm-native when building gallium support ( thats when
llvm-config is effective), its better to point llvm-config into native
sysroot so it can add correct paths into compiler/linker cmdline
(From OE-Core rev: aa91fb2f0af1a32809ab1755598da5986b2dd06d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cc73360b9728812ed6123e30559b77d8e89cc21c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The comment specifies how to use the variables but uses the older and
now unsupported override syntax. Let's update to match the newer syntax.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From OE-Core rev: 0a381eea4d50ff1c6e7c7d0d4df62eb581454b48)
(From OE-Core rev: 0bbafc8b4d0c401a2af7c4b80e86d3e3fe01bed5)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bb64f3fed29b9532e6ddc9a2ba0283d373622d87)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The intent behind these functions was to dump the system state when issues occured
but it has never really worked as we'd planned. Regular monitoring as the build
runs has largely replaced this as that allows a trend to be seen rather than a spot
value which was never really useful. The code is bitrotting and not functioning
correctly so drop it.
[YOCTO #13872]
RP: Reword commit message
(From OE-Core rev: 8d1bc34cffdd9f054e51db4e880747c79bf834fe)
Signed-off-by: Thomas Roos <throos@amazon.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dea37ba49a236029da73d5cfbfc069bffc38b508)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Instaed of allways create the directories and removing it at the if they are
not used, we can just do it when there are modules configuration to be created.
So the best thing to do is install the directories only when necessary.
(From OE-Core rev: 455baf41550431c22047fe718c8eaae71924b23f)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 71460993f350bca3d5a22115fd5551696f955c9f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This needs to be done for any item that is linked under rustc,
and not just rust itself. Latest python-cryptography exposes the issue.
(From OE-Core rev: 967d847a9815df43d0c92ca61cc544e1fe5dcc03)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d3811228747590ea06e8d68be4785d45ec9c478f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
cargo_do_compile runs only if the recipe is built using cargo
as the top level tool. Some recipes hide usage of cargo inside setuptools
(or autoconf) and use do_compile definitions specific to those,
and so the environment isn't properly set up.
This was exposed by latest versions of python3-cryptography.
(From OE-Core rev: a1946efdbec608d47f9e992c1b5cf3c671a204fc)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9f4ff643a028d7f5670d80861f2ce19ca2d90faa)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Remove log_lock.pid which maybe created during do_rootfs. In commit
[dnf: only write the log lock to root for native dnf],
native dnf changed to write log lock to root, and target dnf still
use /var/log, so log_lock.pid need to be removed post do_rootfs.
(From OE-Core rev: 595fbe4c9ad25e52e88d7bcf1d1864fe5ec324a5)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
I've encountered issues reproducing initramfs and UKI image builds,
which will be fixed with this patch.
1. initramfs
There's a symbolic link to /sbin/init, which is appended to the cpio archive after creation.
The links timestamp needs to be static and the cpio append command needs the '--reproducible' flag to produce deterministic outcomes.
2. Unified Kernel Image
'--preserve-dates' is required for a static 'Time/Date' entry.
I've added '--enable-deterministic-archives' although in my case this
didn't change anything.
(From OE-Core rev: 7bf9463665c46e331f40f9ca4f04733d14f9ab44)
Signed-off-by: Frieder Paape <frieder@konvera.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fd027729bafb4e085ba0949e38e724f3a8cad102)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM[1] controls the search
behavior of find_program(). When this variable's value was
first used in OE, it was deliberately set to BOTH to allow
searching of host tools. This is to ensure the necessary tools
from host could be used. The downside is that the configure
behavior may differ on different host environments.
Later, this cmake.bbclass was added the ability to search tools
under the HOSTTOOLS_DIR. This means we no longer needs cmake to
search the host paths. So we remove the class-native setting of
BOTH.
[1] https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH_MODE_PROGRAM.html
(From OE-Core rev: 1e2866eb0ce0c10a2668fbd66bc28526eec30f4d)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f4ea12f6635125ee793f4dd801c538c0186f9dc3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If a specific kernel provider or configuration wants to enable BTF
and pahole analysis, it isn't currently possible due to the explicit
definition to false in the base kernel build arguments.
pahole is now detected by the kernel built itself, so unless
pahole-native is enabled, the result is the same.
If a kernel does require an explicit disable of pahole, it is better
to carry PAHOLE=false in those specific recipes.
(From OE-Core rev: c6f13dcb3e04655c8076c1100ceada760ffb1ddb)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b1e4851a36ed47ce6ba880a49264b9a57c78cf4f)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* since "populate_sdk_base: ensure ptest-pkgs pulls in ptest-runner" change:
https://git.openembedded.org/openembedded-core/commit/?id=ecff0642be5781f7f6cca617158b04ac9a0e85f0
in multilib build when building lib32-foo-image it can pick wrong
ptest-runner package if it was built in the same TMPDIR before the
image, do_rootfs then fails to find it, if the package manager config
doesn't have 64-bit feed enabled:
opkg_prepare_url_for_install: Couldn't find anything to satisfy 'ptest-runner'
(From OE-Core rev: 3cdfdeb8f18dd467e2c5c6e9d6e3739aaf5c0c3d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 4d24749e7e94881bb952f5c927f0012eb70d4390)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
[YOCTO #15108] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=15108
Since the latest change, the PYTHONPATH is overwritten instead of extended.
This leads to changed behavior and build errors of recipes where the PYTHONPATH
is set before setup_target_config is run.
Fixes: c9617c03bcee ("python3targetconfig.bbclass: use PYTHONPATH to point to the target config")
(From OE-Core rev: cf31424aa7ce3308373899181aef0e503ead4776)
Signed-off-by: Johannes Schrimpf <dev@loewen-email.de>
[Luca: add Fixes: tag]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2442ab92f8610784d28d8d83056b643bd95b0b4e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* this in the end doesn't help much, I was debugging warning (about base-files.do_install
signature being different than expected) from:
python3 $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'
this shows the warning on console, but it doesn't end in $LOGFILE, because it
writes only contents of cooker log into the $LOGFILE with:
with open(logfile, 'a') as logf:
logf.write('Preparing SDK for %s...\n' % ', '.join(sdk_targets))
ret = run_command_interruptible('BB_SETSCENE_ENFORCE=1 bitbake --quiet %s' % ' '.join(sdk_targets))
if not ret:
ret = run_command_interruptible('bitbake --quiet build-sysroots')
lastlog = get_last_consolelog()
if lastlog:
with open(lastlog, 'r') as f:
for line in f:
logf.write(line)
if ret:
print('ERROR: SDK preparation failed: error log written to %s' % logfile)
return ret
maybe we could remove whole support for $LOGFILE parameter and just redirect
the output like other commands on this line
(From OE-Core rev: 766c6f7ae72576cfab3654362ae949688f42acce)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 719f22df160ebde303274ccfc04049cffdb51577)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Function 'gen_updatealternativesvardeps' still used old override
syntax when fetching variable flags. Update to use ':' instead to match
recipe meta data. This was found by review and no real issue encountered
but it is a bug that affects variable dependencies and can affect rebuilds
as task hashes might not be accurate.
(From OE-Core rev: 27b4fb60c7c66c245ba50607c8e178390fc41014)
Signed-off-by: Peter Bergin <peter.bergin@windriver.com>
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5691f554b2cd50f256a8cbb1d96781e9eb6b930e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
(From OE-Core rev: 126cbad716377f024dae5cc8e2faee9bd661f5c5)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* otherwise it ends '<unknown>' inside esdk, because of parsing order:
# $METADATA_REVISION [3 operations]
# set /OE/build/test-D/conf/local.conf:43
# "f2da54ef432eac89b0f18eaad68e602b6990b5de"
# immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9
# "${@oe.buildcfg.detect_revision(d)}"
# set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10
# [vardepvalue] "${METADATA_REVISION}"
# pre-expansion value:
# "<unknown>"
METADATA_REVISION="<unknown>"
* This causes base-files.do_install and following tasks to have different
signatures between esdk and the build directory where this esdk was created:
bitbake-diffsigs {test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata*
NOTE: Starting bitbake server...
basehash changed from 5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd
Variable METADATA_REVISION value changed from '<unknown>' to 'f2da54ef432eac89b0f18eaad68e602b6990b5de'
and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK is being prepared for use:
WARNING: The base-files:do_install sig is computed to be 83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201,
but the sig is locked to 3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in SIGGEN_LOCKEDSIGS_t-qemux86-64
[RP: Add commit about why we need the override for future reference]
(From OE-Core rev: a857360c078aa5e03cf113dc2dc87069b0e0201c)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 675ea7281c17f77bf5dea17cfd4d9da0928382a0)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The current check for default dtb image checks if the file exists and is
not empty but appends a slash to the path due to which the file is never
found. It also doesn't replace slash in filename with _ as done when
populating the DTB variable. A better way to check the existence of the
device tree would be from the list of DTBs since this is used during
compilation.
(From OE-Core rev: f8efe7d50860e44cd22a91685d0438c5c73d8557)
Signed-off-by: Arslan Ahmad <arslan_ahmad@mentor.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit e8e31e11b158837804d029e85f5f8ed3c219a4ea)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
With the recent change to the crate fetcher, which automatically sets
the name to for each crate to be versioned, there is no longer a need to
explicitly set the name= parameter for each URI. This also results in
generated files that are compatible with the crate fetcher in Kirkstone
and Langdale.
(From OE-Core rev: eb272afcd9a12ce2b2f43436b3f84f52cb6cdfb7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simply inheriting setuptools3-base should put everything in $libdir in
PN, and there's no need to replicate the pkgconfig packaging rules as
those are the defaults.
(From OE-Core rev: 56a32e31d4fdfb908f0edf513d21bc0f2b8c721e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* when searching for qemuboot.conf
* don't assume that IMAGE_LINK_NAME is always
<rootfs>-<machine> (with <rootfs>-<machine>.qemuboot.conf)
* runqemu: use IMAGE_LINK_NAME set by testimage.bbclass or query with bitbake -e
* testimage.bbclass was setting DEPLOY_DIR which I don't see used
anywhere else, so I assume it was supposed to be DEPLOY_DIR_IMAGE as mentioned
in corresponding runqemu code, do the same with IMAGE_LINK_NAME variable
* add virtual/kernel as bitbake -e target in run_bitbake_env to make
sure IMAGE_LINK_NAME is defined (kernel-artifact-names.bbclass inherits
image-artifact-names.bbclass as well)
* improve .qemuboot.conf search
1st search for file matching the rootfs and only when not found
try again with .rootfs suffix removed
[YOCTO #12937]
(From OE-Core rev: 716eb55bb963db7b02d985849cb025898aabc855)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A project can have multiple Cargo.lock (provides
multiple binaries for example) and each one can
depends on differenct version of the same crates.
Even within the same Cargo.lock file, it is possible
to have different version of same crates.
To avoid conflicts, override the name with the version
for all crates checksum
Moreover, when searching for Cargo.lock, we should ignore
specific dir like .git (no use to walk down there) and .pc
(because it can have a Cargo.lock if this file was patched)
(From OE-Core rev: 1795e98a04ad09b011afcc7cc3bf6dc49475b19a)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since disable network was added cargo configurations which reference git
repos fail as they attempt to fetch across the network as part of
do_compile, even if EXTRA_OECARGO_PATHS to add them as part of `paths`
is used, as this is documented as only working for packages which exist
in crates.io.
Add parsing of the SRC_URIs for git repos and include `[patch]` sections
to redirect to the checked out source repos which the bitbake fetcher
has already populated.
There are still cases which don't work - if you have multiple copies of
the same repo with different revisions, there's currently no way to
represent that and anything using a repo which has a virtual manifest
will fail to build (see https://github.com/rust-lang/cargo/issues/4934).
(From OE-Core rev: 684a8af41c5bb70db68e75f72bdc4c9b09630810)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to make it easier for projects to avoid default -${MACHINE} suffix if
the ${MACHINE} named DEPLOY_DIR_IMAGE works better for them
* also use IMAGE_LINK_NAME in IMAGE_NAME to make it more clear
that IMAGE_NAME is the same as IMAGE_LINK_NAME but with version
suffix
* adding it as separate variable helps us to catch the cases
where we didn't respect ${IMAGE_LINK_NAME} variable and just used
the common default ${IMAGE_BASENAME}-${MACHINE}.
[YOCTO #12937]
(From OE-Core rev: 6e82c394e98d57a2fe73e547922477cd6b0620f9)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* move it from kernel.bbclass, because it needs to stay in sync with
IMAGE_LINK_NAME structure
* image-artifact-names.bbclass is also inheritted from kernel-artifact-names.bbclass
so every recipe which needs this variable probably already inherits one of these
* fixes kernel-fitimage.bbclass with modified IMAGE_LINK_NAME
[YOCTO #12937]
(From OE-Core rev: 432d0df0d771c8f0bef1e855ac6b0011b2c3cad2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There should not be any network access during the build step so
specify this explicitely to cargo.
This will allow better error message, e.g:
| Caused by:
| can't checkout from 'ssh://git@.../fmartinsons/zbus-git-dep-test.git': you are in the offline mode (--offline)
Instead of
| Updating git repository `ssh://git@.../fmartinsons/zbus-git-dep-test.git`
| warning: spurious network error (2 tries remaining): failed to resolve address for gitlab.com: Temporary failure in name resolution;class=Net (12)
(From OE-Core rev: 8e9ec03c73e8c09e223d6f6cce297df363991350)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure to expand all MKUBIFS_ARGS_<label> and UBINIZE_ARGS_<label> vars
in 'do_image_multiubi' task to use them to init the local 'mkubifs_args'
and 'ubinize_args' vars.
See [YOCTO #15065]
(From OE-Core rev: 09d05215cf61981c7bc828cc0ff64c2fd5edc43c)
Signed-off-by: Romuald JEANNE <romuald.jeanne@st.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages like lirc places its unit files into $systemd_user_unitdir
and also uses them in SYSTEMD_SERVICE list in recipe. This fails in
do_package
ERROR: Didn't find service unit 'lircmd.service', specified in SYSTEMD_SERVICE:lirc.
here lircmd.service is installed in /usr/lib/systemd/system/lircmd.service
(From OE-Core rev: 12808a4159835b67d8d53d32bc9135811701a779)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows avoiding clashes between source archives of a main
project and a pypi project using the same name and version.
The new optional setting is PYPI_ARCHIVE_NAME_PREFIX which is empty
by default so previous downloads can be used. Example usage:
PYPI_ARCHIVE_NAME_PREFIX = "pypi-"
(From OE-Core rev: 6f9a6a3dbe5c8eb9f0d19987410932fec3d6dd1a)
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As vname var is needed in multiubi_mkfs() function, we need to keep it
defined and use it as parameter to the new write_ubi_config() function.
See [YOCTO #15027]
(From OE-Core rev: 8b5e1cce35e129b21d871ab45b03811fdb6eaf8f)
Signed-off-by: Romuald JEANNE <romuald.jeanne@st.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All the usage sites remove the -ptest suffix. Simply the original list
instead and clean up the code.
(From OE-Core rev: 4a28057849f9edc6ac06d115531f579673d788b5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The script generated by the sdk_ext_postinst function was not quoting
the user existing PATH when updating it causing the export command to
fail.
Add necessary double quotes around $PATH.
(From OE-Core rev: 00e96bf250eaaded839caf465dbc0af5b604aed7)
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The environment-setup script generated by the recipe was not quoting the
user existing PATH when updating it causing the export command to fail.
Add necessary double quotes around $PATH.
(From OE-Core rev: 42177ff2d45ee70ad00917bb6fbabca49dae4f59)
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you build an image with lots of manpages in, then each package will
run mandb inside qemu-user at rootfs time. This is a slow operation
and should be done once when all of the packages have installed using an
intercept instead.
The call to mandb has been changed too. mandb doesn't actually allow
the configuration file to be read from stdin so that was being ignored,
instead write the file to a temporary file and use that.
This means we then don't need to tell it where to search explicitly, and
it writes the indexes to the correct paths so we don't need to move
files afterwards either.
Sadly we do still need to run mandb inside qemu-user, as the underlying
database is a gdbm file and they are byte-order dependent.
For my test case of core-image-base with api-documentation
DISTRO_FEATURES and doc-pkgs IMAGE_FEATURES enabled, the performance
gain is significant:
core-image-base do_rootfs -1303.1s -73.6% 1771.6s -> 468.5s
(From OE-Core rev: fbd8a57aa307bfda70a08cb78af3c97f05c39a3a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pkgconfig is being required to find dependencies for building kernel
native tools, move "inherit pkgconfig" to kernel.bbclass so BSP kernel
recipes can also benefit from it.
(From OE-Core rev: 8a84bd98e3fbc16c782f83064801e469d086911e)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in switching toolchains cleanly for kernel build
between gcc and clang
Currently, some kernels allow building with clang but not all
the distro might use clang as default system compiler but kernel
may demand gcc which is provided via KERNEL_* variables, however
kernel does use OBJCOPY at places during build and it maybe set
to use llvm objcopy when using clang. That should be a deliberate
setting when clang is used for kernel as well, otherwise it should
use binutils provided objcopy
(From OE-Core rev: 17b409f2fd97894e0943d13c2cb0d52abde647e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
