Mitigate occurences where ':append' operator is used and leading
whitespace character is obviously missing, risking inadvertent
string concatenation.
(From OE-Core rev: fcd340ec53ff8352b8cae0eb351810072b025a08)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade to U-Boot 2023.01.
Remove the two patches that are now upstream:
e67f34f778ba ("riscv: support building double-float modules")
1dde977518f1 ("riscv: Fix build against binutils 2.38")
And add a patch that fixes u-boot-tools build.
(From OE-Core rev: ec69f295552d6dd4de755bb4562a007158cf660e)
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove package_tar.bbclass, which is no longer in use in oe-core
and meta-oe, and which the document reports as broken and unsupported.
(From OE-Core rev: 90ce19122802a16e6067f3a2ce3447acf1070fe5)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add options to enable support for libcloudprovider and tracker
If the cups backend is enabled, the mandatory file backend gets disabled and
thus configure fails. Fix it by not defining the print-backend and just include cups
as a dependency. Additionally add it as a runtime dependency.
Now, if cups gets enabled, it should include the following print-backends
by default: cups,lpr,file
(From OE-Core rev: 5ac88d032968f4d005a61fc34f7e3e6e55426ccd)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Latest compilers are able to figure out that whole code can be optmized
away when CFLAGS has -O2 or more agressive optimizations. In order to
ensure the test is doing the right thing, make the variables global so
compiler is not able to optimize it away.
This fixes build on x86 especially when using clang compiler
(From OE-Core rev: e9c4017982a5556580d24e72e74c4d5a879ff11c)
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>
Add an initial value for the new bitbake BB_HASH_CODEPARSER_VALS support,
which optimises the codeparser cache's size and stops it growing at every
parse.
(From OE-Core rev: 7c15e03dd30abe43d784f41e3c04c96a7bbb0d62)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3-cryptography-crates.inc: update for 39.0.0
* python3-cryptography-vectors: upgrade 38.0.4 -> 39.0.0
Highlights from Changelog:
https://cryptography.io/en/latest/changelog/#v39-0-0
39.0.0 - 2023-01-01
* BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.1.0 has been removed.
Users on older version of OpenSSL will need to upgrade.
* BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 3.5. The new
minimum LibreSSL version is 3.5.0. Going forward our policy is to
support versions of LibreSSL that are available in versions of OpenBSD
that are still receiving security support.
* BACKWARDS INCOMPATIBLE: Removed the encode_point and from_encoded_point
methods on EllipticCurvePublicNumbers, which had been deprecated for
several years. public_bytes() and from_encoded_point() should be used
instead.
* BACKWARDS INCOMPATIBLE: Support for using MD5 or SHA1 in
CertificateBuilder, other X.509 builders, and PKCS7 has been removed.
* ANNOUNCEMENT: The next version of cryptography (40.0) will change the
way we link OpenSSL. This will only impact users who build cryptography
from source (i.e., not from a wheel), and specify their own version of
OpenSSL. For those users, the CFLAGS, LDFLAGS, INCLUDE, LIB, and
CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS environment variables will no longer
be respected.
(From OE-Core rev: 904574c49c51f1862c6b888a3e5889bd972df42d)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes build use compiler to decide from where to get atomics
instead of assuming that it should always come from libatomic, helps
sharing build artifacts with OSes which may not have libatomic installed
because it is not required on those hosts.
(From OE-Core rev: a026d9afcbe07a8324ca951ba3439373dcb3771c)
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>
Back when it was merged in https://git.yoctoproject.org/poky/commit/?id=c4257ed8b1040a5a0e9a95846d81961741239116
it appeared special handling in setVar was necessary. Likely due to
other fixes and improvements it no longer appears to be. The results of
"bitbake world -g" before and after this change are identical for oe-core
and meta-openembedded. Therefore drop the "parsing=True" special parameter to
setVar() meaning overrides can now be cleared.
This means that something like:
DEPENDS:append = " bash"
now functions as expected, adding bash to the target recipe and bash-native to
the native BBCLASSEXTENDED version.
Without this change, it would add bash to the native version as well as
bash-native which is clearly incorrect.
[YOCTO #15010]
(From OE-Core rev: 99a5105f7b5303cd36077b5910c662a865c1782c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sgdisk still segfaults for some tasks (e.g 'sgdisk -v', 'sgdisk -V')
Add a follow-up patch that fixes the issue. It was taken from Archlinux
(From OE-Core rev: b2f3f8ced22da68eecd7689cc09e28f70100bd56)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If multiple compression libraries are enabled, the format to use for
compression is chosen implicitly, so if you want to compress with e.g.
lz4 you cannot enable zstd, so you cannot read zstd-compressed journal
files. This PACKAGECONFIGs allow to enable all compression formats for
reading, but to choose a specific one for writing.
(From OE-Core rev: bec1e2628e7accf2eff07193ae5ea14eb443ae37)
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some users of _findVar don't need the override data and even
getVarFlag doesn't need it in some common cases (parsing=True).
Rearrange the code as the current overridedata approach doesn't need
to be in the _findVar code anyway. This removes some search overhead
from a critical path.
(Bitbake rev: fcb64e1138a20eb19560af3fc5d1fa748cc9cf34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the codeparser cache ends up being extended for every parse run
since there are values in the functions such as the result of os.getpid()
from LOGFIFO in OE-Core.
Digging into that issue, there are also lots of similar but different
functions being parsed where the change might just be a path to WORKDIR,
a change in PN or PV or something like DATE/TIME.
There is no reason we have to use these changing values when computing the
dependenies of the functions. Even with a small tweak like:
BB_HASH_CODEPARSER_VALS = "LOGFIFO=/ T=/ WORKDIR=/ DATE=1234 TIME=1234 PV=0.0-1 PN=nopn"
the cache is reduced from ~4.6MB, increasing by ~300kb for every parse run
to around 1.3MB and remaining static for oe-core and meta-oe. In my local
build, admittedly heavily experimented with, the cache had grown to 120MB.
The benefits of doing this are:
* faster load time for bitbake since the cache is smaller to read from disk
and load into memory
* being able to skip saving the cache upon shutdown
* lower memory footprint for bitbake
* faster codeparser data lookups (since there is less data to search)
We only use these special values when passing code fragments to the codeparser
to parse so the real variable values should otherwise be used in the hash data.
The overall effect of this change, combined with others to avoid saving unchanged
cache files can be ~2s on a ~16s parse on my local system and results in a more
responsive feeling bitbake. It also allows parsing performance to be investigated
more consistently.
(Bitbake rev: f24bbaaddb36f479a59a958e7fc90ef454c19473)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When draining the result queue from the parsing processes, cache objects
can be created even if they are then immediately destroyed. The reset
in the sync code needs to happen after any objects have been created.
Change the ordering to fix this. This ordering has caused various
cache errors, particularly when interrupting parsing with Ctrl+C.
(Bitbake rev: f45a94e6720dacf7f51ac147c115a6f608769093)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By writing the cache files only if there is data to write, we can save a
bit of time.
(Bitbake rev: abeff1f80bb1c690b92d535d472dff9df7a56067)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to reset the cache before the start() call which starts the
parsing processs, tweak the code to ensure this is the case.
(Bitbake rev: 4712d6237df5d2188238294fbdb9f107b068a3a7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to check against the first line of the file, fix the typo.
(Bitbake rev: 4abc598fb01d426394f4222dfc752e620a8e1b7b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently INIT_MANAGER cannot be overridden from local.conf. This is
complicated by the use of overrides in the various poky distro configs.
That is necessary, so use a separate variable to indirectly set the value
meaning local.conf can still override the result.
(From meta-yocto rev: da23d0c3edad0f5ee4cc4916276e214e8d53aad0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, whilst patch errors or warnings are shown, the errors don't stop builds.
The configuration isn't very configurable from WARN_QA and ERROR_QA either.
This patch:
* Uses the standard mechanisms to handle the patch fuzz warnings/errors
* Makes Upstream-Status checking configurable from WARN/ERROR_QA
* Allows that checking to be used with non-core layers
* Makes patch-fuzz an error by default
(From OE-Core rev: 76a685bfcf927593eac67157762a53259089ea8a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While the parameter is not required it allows testing of possible
regression in fetcher code when parameter specified and mirrors are
used.
(Bitbake rev: 1a21918049091a6d77426dbf8868ffdc14ba1003)
Signed-off-by: Pavel Zhukov <pavel@zhukoff.net>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when current test platform doesn't have 2 or more CPU node, the test
case would report FAIL, according to numa test script and numademo
code, when return code=77 should be skip test, so using SKIP instead
of FAIL in test script.
(From OE-Core rev: fd0a82400d419bce8605a9445db9b20b8ddc01a7)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE is the main user of pseudo and we've had the changes in the oe-core branch
around long enough that we're going to run with them. Swicth back to directly
using the master branch.
(From OE-Core rev: 16bce7aa85ef6b77fc9117aa22f81f15e4c8d8fc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Luca: re-add 'branch' parameter to fix "does not set any branch parameter" warning]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update to pull in:
pseudo.c: Avoid patch mismatch errors for NAMELESS file entries
In rare cases we see failures, often in linux-libc-headers for things like:
| INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include
| abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
Pseudo log:
path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req '/XXX/linux-libc-headers/6.1-r0/image/usr'.
Setup complete, sending SIGUSR1 to pid 3630890.
Whilst this doesn't easily reproduce, the issue is that multiple different processes are
likely working on the directory and the creation in pseudo might not match accesses
made by other processes.
Ultimately, the "NAMELESS FILE" is harmless and pseudo will reconcile things
so rather than error out, we should ignore this case.
(From OE-Core rev: 4f30a1a74828e105cbe69677b3fbe5623f371543)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its deprecated in upstream fmt as well. Moreover it helps compile with
latest compiler
(From OE-Core rev: 01ef766ada47cd845643c632160e1808fa237d1c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The effect of subsequent setup-layers executions is now either a NOOP
or the minimal set of changes required to ensure layers precisely match
the JSON configuration.
This change allows setup-layers to be incorporated into a team's
configuration management strategy. In particular, the configuration
JSON manages a "pinning policy" that documents the oversight of sources
of change (a requirement for embedded development in highly regulated
industries).
One model for this strategy would work as follows. Team level policy is
developed to regularly review upstream commits that occur between the
current upstream HEAD and the previously pinned revision. The JSON
configuration is periodically updated after a review, test, and approval
process. In the rare instance that an upstream change is considered
problematic, the bbappend mechanism can be used to make relevant
changes in the team's project repository. This approach also requires
that team developers regularly run the project repository copy of
setup-layers. This is most easily accomplished by including setup-layers
in a wrapper script that all team developers use to interact with the
bitbake tool suite (e.g. "bb bitbake foo-image"). Project level policy
and oversight is effectively "contained" within this wrapper script,
thereby reducing a significant source of human error.
Left unstated, but acknowledged here, are a number of nuances required
to successfully implement the above strategy. The details are out of
scope for this explanation. What should be clear is that a larger
configuration management strategy can now benefit from the utility
provided by setup-layers.
Note: Neither the above configuration management strategy example nor
the change itself is intended to alter the original intent to use
"bitbake-layers create-layers-setup destdir" to keep pace with upstream
activity for those who wish to use it that way.
(From OE-Core rev: da2e01cacd98715318a5307fe0618dbca0cf1fe7)
Signed-off-by: Chuck Wolber <chuck.wolber@boeing.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop backported 0001-fix-mm-slab_common-drop-kmem_alloc-avoid-dereferenci.patch
0009-Rename-genhd-wrapper-to-blkdev.patch is present only on the master branch
and not on 2.13 branch, so keep it in the recipe.
(From OE-Core rev: 5b04d4cea291b8d816a3a8d880004506fbf2b390)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This MAGIC variable is used by libmagic (file), and should
be exported by the file recipe.
As the rpm recipe has 'file' in its DEPENDS, its sub-packages
which links to libmagic will be automatically added the 'file'
runtime dependency. More specifically, it's the rpm-build package.
So in case components in nativesdk-rpm-build package uses libmagic,
the nativesdk-file package will be installed and the MAGIC var
will be exported.
(From OE-Core rev: 6e2147ab1d0f3aad2dfe8180a3896c9c9bcfdac8)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
