We met a problem that core-image-tiny-initramfs's SDK cannot be
installed. The error message is like below.
tar: ./sysroots/core2-64-poky-linux/dev/console: Cannot mknod: Operation not permitted
In fact, the '/dev' direcotry is not needed by SDK. So remove it.
This patches uses a variable, SDK_PRUNE_SYSROOT_DIRS, to hold useless dir entries
so that it could be extended. For example, '/usr/bin' could be added if wanted.
(From OE-Core rev: 9154f71c7267e9731156c1dfd57397103e9e6a2b)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
this should prevent running into the very rare error
sqlite3.OperationalError: attempt to write a readonly database
As highlighted by https://www.sqlite.org/faq.html#q5
it is likely that the adapter won't allow use multiple exec calls
at the same time.
So it's best to prevent multiple accesses at a time, by reusing
the already in place CVE_CHECK_DB_FILE_LOCK
YOCTO #14110
(From OE-Core rev: 677f5741bd265be49d4a5bb933b3e8d8c4eec653)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qemu class declares functions which are architecture specific. If a user such
as meson is used in an allarch recipe, this leads to sstate which is machine
specific. To fix this, remove the architecture specific part, since there are no
binaries in allarch classes, this change shouldn't break anything.
(From OE-Core rev: 049879ba842d89f268b8e3a4e26410d13bc54158)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch was merged on the basis that it wasn't needed with recent versions
of qemu. That isn't true and has been showen to cause failures for aarch64 on
centos7 hosts. Revert the patch as we'll need a different solution.
This reverts commit 94b371e1c9.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a couple of function name typos copy and pasted between the classes.
(From OE-Core rev: f99b98341cfb849680461cfa2992f854eebad5df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Go has its own system for creating temporary build
sub-directories with randomized names, and setting
up debug-prefix-map on the fly to prevent those
directories leaking into target binaries. OE's own
settings were clashing with it, so this change
carefully avoids the two stepping on each other.
Additionally, the top level build directory cannot
be named 'go-something'.
(From OE-Core rev: 9985b17a30bb9b9f1bc82a44662687db5cead66e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
go writes build-specific ids into binaries it produces
and has a custom system for calculating them from
file hashes, environment variables and other inputs
(not that dissimilar to sstate cache, actually). This can
go wrong :) in various ways (for purposes of reproducibility
in particular), so this enables useful logs to see what
happens and why.
(From OE-Core rev: a587be1d18fc55fe57d1aa5aa7c9e26af887109e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dependencies for do_build became a little too minimal after the
removal of recrdeptask since "bitbake go" would not package go-runtime
despite it being in DEPENDS and the resulting package having a dependency
on it.
A reasonable compromise is probably rdeptask instead of recrdeptask
which is a lot lower overhead but makes the build target more useful
and importantly, lets world builds do what you'd expect them to.
(From OE-Core rev: f3d02c328f3f182340528d11c7b10454e3f6a54b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding the dbg package allows the package bbclass to parse the
debug information which can then be used by the create_spdx bbclass
(From OE-Core rev: b35b68e4ec4a82ada20ab861d29f96cdcb21dec2)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow .bin suffix to be removed (or changed) in the various artifact
filenames. Removing this extension is useful when trying to remove
symlinks and present only unversioned image files (especially for the
FIT image).
(From OE-Core rev: cbecc3cf06eb7359fedf3c6af281cc72178cad18)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If IMAGE_LINK_NAME is empty (supported everywhere else) then do not
create the symlink for the .qemuboot file.
(From OE-Core rev: 9b19845c0506949ca61965fb92fb3f337062f377)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow setting any of the *_LINK_NAME variables to empty string in order
to disable creating symlinks for kernel artifacts, as you can already
for filesystem images with IMAGE_LINK_NAME. Additionally, for the image
type named symlinks, add a KERNEL_IMAGETYPE_SYMLINK boolean variable
which you can set to 0 to disable those symlinks as well.
(From OE-Core rev: d7341f1f22c32ff6cc95d7127f26f87d7fc9c6bd)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
which is introducing task hash changes for some
allarch package builds, and should no longer
be needed with recent versions of qemu.
(From OE-Core rev: 3a3cfb5f48fc92e548333e5856f3d3fcce27da46)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The append/override ordering was meaning that whilst the data was being picked
up later in the package processing, it wasn't being picked up by do_package.
This means changes to qemu options were not causing task signatures to change.
Fix the variable ordering with the append to correct this.
The whitespace fix is deliberate to cause output to change and hopefully avoid
hash invalidation issues from unchanged output.
(From OE-Core rev: 407793a0fd4e562b626ff07024c5bbdc2a65b20e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds a smoke check for whether the rust toolchain actually
produces working executables across a range of architectures.
(From OE-Core rev: 14bb638b0df7acfa6aa89abf4625357f8cde886b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
previously used package_qa_check_src_uri was triggered during
package_qa stage, which implies having packages.
This isn't the case for native-only recipes or recipe that inherit
nopackages.
Still the checks performed (src-uri-bad) apply to those as well.
Therefore move the check from package_qa stage to unpack stage.
(From OE-Core rev: 8fe68a0516df25a9f336c9f5156a6895d65c0820)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
as defined by latest addition to the commit message guideline
(From OE-Core rev: 05c39d9ee820c5807353d1f147fb36596466d03b)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class provides an image feature that mounts /etc as an overlayfs
file system. This is an extension for existing overlayfs class, which
doesn't support /etc
(From OE-Core rev: 610ea808c8b5edb2826bda1f1c42a811bd4ba758)
Signed-off-by: Alfred Schapansky <alfred.schapansky@avantys.de>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGE_SNAP_LIB_SYMLINKS renames libraries based on their SONAME so
that they can be found directly rather than going via symlinks that
would be created by ldconfig. For example, without
PACKAGE_SNAP_LIB_SYMLINKS in ${libdir} we have:
libharfbuzz.so.0 -> libharfbuzz.so.0.20600.4
libharfbuzz.so.0.20600.4
but with PACKAGE_SNAP_LIB_SYMLINKS="1" we have just:
libharfbuzz.so.0
Unfortunately, this renaming is done based on the SONAME which breaks
packages like mesa which install a single library with multiple hard
links:
-rwxr-xr-x root/root 13593488 2021-12-07 12:26 ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-12-07 12:26 ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/iris_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
The SONAME for i915_dri.so (and therefore all the other names that link
to the same file) is libgallium_dri.so. This means that
PACKAGE_SNAP_LIB_SYMLINKS causes do_package to successfully rename the
first name found to libgallium_dri.so. A similar thing happens to
i965_dri.so with its SONAME of libmesa_dri_drivers.so. The order is not
deterministic, so this means that although every build will be missing
one name, it's not always the same one.
-rwxr-xr-x root/root 13593488 2021-11-30 15:17 ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/libgallium_dri.so link to ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-11-30 15:17 ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
This renaming means that the library cannot be found at runtime.
The simplest way to avoid this renaming is to only snap libraries that
would be processed by ldconfig.
(From OE-Core rev: 8571182ece1602ce8e030c98aef17cdc5718a037)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some BSPs, especially those of meta-freescale and meta-ti allow to build U-Boot
binaries using different configuration for a given target, for example:
- UBOOT_CONFIG ??= "tfa-secure-boot tfa"
- UBOOT_CONFIG ??= "nand sdcard spi nor"
When this is the case the public key wasn't concatenated to all U-Boot binaries
built.
(From OE-Core rev: dfd71ae3d102f3010c6117d774e9739a322930f6)
Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in
kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather
than KERNEL_IMAGETYPES. This broke the special handling for fitImage
immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains
fitImage.
It has always been my understanding that KERNEL_IMAGETYPE_FOR_MAKE
controlled what was passed to make, but KERNEL_IMAGETYPE controlled what
was installed/deployed. When the two are different then it's the
responsibility of whoever set KERNEL_IMAGETYPE_FOR_MAKE to ensure that
whatever comes out of the kernel build system has been transformed in to
the requested form by the time of installation. This is what happens for
kernel.bbclass's own support for vmlinux.gz.
I think this means that for KERNEL_IMAGETYPE vmlinux.gz, kernel.bbclass
is responsible for generating vmlinux.gz.initramfs[1] so that
kernel_do_deploy can deploy it. This means that the change in
526bdd88ccd758204452579333ba188e29270bde can be reverted, fixing
KERNEL_IMAGETYPE = "fitImage".
In addition, it ought to be possible for recipes and other classes that
use kernel.bbclass to hook into this mechanism by setting
KERNEL_IMAGETYPE_FOR_MAKE and performing their own transformations.
do_bundle_initramfs calls kernel_do_compile and we don't want it to
transform vmlinux to vmlinux.gz at that point, since it will fight
against the careful renaming and preserving that do_bundle_initramfs
does. Let's separate the transformation out of kernel_do_compile to a
new do_transform_kernel task that can be run at the right time. This
means that it's also logical to perform the equivalent translation for
the kernel with the initramfs in a separate
do_transform_bundled_initramfs task too.
This leaves two clear customisation points for recipes and other classes
to hook into the process and perform their transformations:
do_transform_kernel and do_transform_bundled_initramfs.
(I care about this because our recipes that use kernel.bbclass also set
KERNEL_IMAGETYPE_FOR_MAKE and transform vmlinux into a form suitable for
our bootloader after do_compile and do_bundle_initramfs into the format
matching KERNEL_IMAGETYPE. I'm unable to successfully bundle an
initramfs after 526bdd88ccd758204452579333ba188e29270bde, but I didn't
want to just revert that change to reintroduce the bug that it was
fixing.)
I can't say that I'm entirely happy with this change, but I'm unsure
what to do to improve it. I find the way that both the bare kernel and
the one with the initramfs both get deployed to be confusing, and a
waste of build time. I would like to not actually generate a publishable
kernel image at all during do_compile when an initramfs is in use, but I
suspect that this would affect valid use cases that I'm not aware of.
(From OE-Core rev: 10a4a132e87e835726bf5da81a60f6f509b90765)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
[1] It could be argued that this should be vmlinux.initramfs.gz, but
that would require another special case in kernel_do_deploy and the
filename is only visible within this class and the recipes that use it
anyway.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've recently seen issues where libxkbcommon was changed in/out of debian
renaming and weston which DEPENDS but doesn't RDEPEND on it would show build
failures.
Looking at the sigdata file for weston:do_package_write_XXX, there were
dependencies on packagedata for RDEPENDS but not DEPENDS. Some items like
libxkbcommon are in DEPENDS but become autodetected RDEPENDS. The debian
class already handles RDEPENDS but needs to handle DEPENDS in a similar way
to avoid failures since bitbake treats them as two separate namespaces (unlike
recrdepends).
(From OE-Core rev: 834f7d735286c47765beb65778634eec7c2bd64f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This replaces the specific gtkdoc wrapper setting
(which was rejected by upstream in https://github.com/mesonbuild/meson/pull/9627)
with a generic, officially supported and documented exe_wrapper,
which is enabled subject to qemu usermode support
(just as is done for g-i and gtk-doc with autotools).
gtk-doc support is adjusted so that this wrapper is passed to
meson's gtk-doc module, which passes it to gtk-doc.
The adjusted patch is re-submitted upstream.
The side effect of this is that meson is now able to run
target binaries in a generic way when it wants to, so this
may affect cross-builds - hopefully in a positive way.
(From OE-Core rev: 17fb047282a413aae5af991ecf5bbb225e19581e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds a smoke check for whether the Go toolchain actually
produces working executables across a range of architectures.
(From OE-Core rev: 2819bb2cf22c6cfcaeaee79f0280097ec9cb9327)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In almost all cases there is no need to explicitly ask for it via local.conf
or similar custom config:
it is enabled in qemu_use_kvm() if target_arch == build_arch or both of them are x86 archs,
and QEMU_USE_KVM is set.
If that heuristic doesn't work, QEMU_USE_KVM = "" will do the disabling.
(From OE-Core rev: c2a2d475a976225e3a4eb687af6d2a62dca1d2bf)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
distutils is going away and we have functionality in bitbake which can
handle these comparisions so switch to the bb.utils function.
(From OE-Core rev: fe624b520e6c75e16a8f394785ab0216341402f9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a wrapper around ar calls for native/cross recipes. This wrapper adds
the -D option so that deterministic archives are built for native/cross
output. This improves the changes of hash equivalence matches and hence
build artefact reuse.
We don't need this in the target case since we compile binutils-cross
with an option making this the default. We need a wrapper since we need
to remove the "u" option and replace it with "D" but also allow things like
"--version" to continue to work too.
(From OE-Core rev: 59922c95fcb20c66634c5677012d490be2246b0b)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We disable the useradd code for nativesdk targets since we don't support
postinstalls or multiple users in those cases. This means any usage
of chown/chgrp inside do_install tasks won't work and would have to be
conditional. Rather than require all recipes to do that, add intercepts
of the calls and map those to root/root user/groups. We can't just ignore
them as some calls are used to remove host contamination from the host
user ID so they need to be made, just as root.
(From OE-Core rev: e1f40670c438e33cae87678425de72ca03566888)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a similar manner to cml1.bbclass, we export the pkg-config
variables to allow a direct call to pkg-config access to the
native sysroot versus the target sysroot.
The kernel doesn't use pkg-config for target configuration,
and has many explicit calls to pkg-config, without the
possibility of easy override to pkg-config-native.
The calls to pkg-config could be made cross friendly via
replacement with make variables, but until that effort is
undertaken upstream, we need a bridge approach.
In particular, this is required for dtschema validation,
which is a requirement in kernel 5.16+
(From OE-Core rev: 9172d61c57e23682c3d2c25701cbd53c84d01a27)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Give this thread pool a name for clarity.
(From OE-Core rev: 57ea50fcfe81f47b93b9302d1aab2e81dcdd3105)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
base-image boots in degraded mode when using systems without display
system since there is no fb device detected and pslash service would
fail to start. Removing this image feature means that core-image-base is
complete for headless devices
[RP: tweak the false case so it builds]
(From OE-Core rev: 7a6dbad7bf12d2f27f21a81a31a5173cacb49228)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The buildhistory_list_pkg_files function uses data from do_package, not
do_packagedata. Usally the two are restored together but it may see
a half complete directory or other races issues depending on timing.
Rework the function so that it uses the correct task dependencies. This
should avoid races but means the data is only restored to buildhistory
if the do_package or do_package_setscene tasks are restored.
(From OE-Core rev: b83823ce44e7531bbd2bfa62062c04147a11f724)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code was assuming that the a recipe with only one srcrev wouldn't "name"
it. This isn't the case as the glibc or bzip2 recipes show, you can have
a single srcrev which is named.
We can pull the data from the fetcher and in fact we already have it, we just
need to handle the "default" case and make that code the default for all srcrev
regardless of length.
[YOCTO #14017]
(From OE-Core rev: 45ae567932ba52b758eb41754453e9828d9533a1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've bumped the minimum bitbake version past the point this fallback code
was needed, drop it.
(From OE-Core rev: c45ad27f3c43c9bbde5c4d19237411fdbc66920e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reworks the crate fetcher class to have it install the fetcher at recipe
finalization so that it is always available before SRC_URI is expanded.
In addition, override the value of SRCPV to also install the fetcher
when SRCPV is expanded so that AUTOREV works.
[YOCTO #10867]
(From OE-Core rev: bc66c5dd65fb654af5cd91b47f9b4f7a5f53436e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Process all systemd-sysusers configuration files in order to create
users/groups at build time. systemd-sysusers would try to create them at
run-time, but for read-only rootfs that's not possible and results in
warnings from different services:
systemd-udevd[166]: /lib/udev/rules.d/50-udev-default.rules:39 Unknown group 'render', ignoring
systemd-udevd[166]: /lib/udev/rules.d/50-udev-default.rules:40 Unknown group 'render', ignoring
systemd-udevd[166]: /lib/udev/rules.d/50-udev-default.rules:42 Unknown group 'sgx', ignoring
(From OE-Core rev: f86ffdb1b77c6ba32ec250545a40c1c54f983f21)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds the rust tools to the cross and native files if present so that
projects that use both rust and meson can build
(From OE-Core rev: 0ec40fa3aff233bd0dde0461299150786da956ef)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the do_create_runtime_spdx task fails with a Key Error if a
dependency is not contained in the package providers dictionary. Add a
check before using "dep" as a key in "providers".
(From OE-Core rev: 140ce5ef5e8f10251091660e3ef76f315f409076)
Signed-off-by: Andres Beltran <abeltran@linux.microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If LICENSE_PATH is not set, then the split() will fail on a NoneType.
(From OE-Core rev: d6260decae6d2654f6e058f12ca02d582a8ef5a4)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a function with the same name is_work_shared() in the archiver class
this causes a conflict when both classes are included. Use work-shared as the
check in WORKDIR to allow for other packages beyond the kernel and gcc that
use a common shared-work source directory.
(From OE-Core rev: 18eab77ee65c73b17225e69c7ba446ab1c69fa92)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existence of missed files on the local sstate cache is the
condition to search for it on the sstate mirror.
The missed collection are populated when we search the files
on the local sstate cache.
- When we have sstate mirrors we don't need to iterate all files
again because we already know what's missing.
- When we found a file on the sstate mirror is because of they
are missing on the local sstate mirror.
So avoid checking if the hash exists on the missed collection.
- When we can't find the file on the sstate mirror we don't need
to add the hash again to the missed collection as it already exists.
(From OE-Core rev: 46e1f9a900e2be1abeda0dc540fc14040ecd0d7c)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We only have the progress bar when there are more than 100 objects.
So we can check for this and store the result to show the progress bar.
(From OE-Core rev: 18e7a77aa1626e11820804ad64b86a32f97da2ca)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We exclude allarch packagegroups from rebuilding when their dependencies change.
The reasoning is that we are just depending on a name so having these rebuild
lots is just pointless and inefficient. We also don't want them duplicated for
multiple machines for efficiency.
In general this works fine, as long as the package names don't change. That
is also rare but there is one corner case which does catch users out - debian
package renaming. When this does break, users question sstate and so on and
lose faith in the system even if this is a known choice we made.
This commit adds an error message if an allarch packagegroup depends on any
package which shows package renaming in action (through the PKG variable
being set).
If you run into this issue you either need to remove the dependency from the
packagegroup or mark the packagegroup as tune specific, i.e. set:
PACKAGE_ARCH = "${TUNE_PKGARCH}"
before the packagegroup inherit.
[YOCTO #7298]
(From OE-Core rev: 5bf3e447d2f5064495d83a8fad30229bcf1ecc9b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
