5.19 will be removed shortly, bumping the preferred versions for
poky/poky-tiny to 6.1. The -alt config remains on 5.15.
(From meta-yocto rev: 535ef93ef68af20b06effb0dd899895a192bb412)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
6.1 has been soaking for a while now, so it is time to bump the
default qemu version to 6.1 and prepare to remove 5.19.
(From OE-Core rev: 91c1f7d4eb9ec5ad683c798812395df3a56747ba)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On master oe, build a qemuppc64 with systemd as default init, when we
use nfs bootup, the kernel might panic due to missing symbol in dynamic
libraries as below:
hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0
/sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1
Call Trace:
[c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable)
[c000000007443be0] [c000000000103524] panic+0x170/0x3cc
[c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50
[c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0
[c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30
[c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0
[c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250
--- interrupt: c00 at 0x7fff9ed9e840
NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000
REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard)
MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000
One or more of the libraries systemd depends on failed to load due to
unresolved symbols/functions. This was intermittent - with a failure
rate estimated between 5% and 30%.
After checking the code, this issue happens on gcc 12, kirkstone is using
gcc 11 works well, with both using the exact same v5.15.84 kernel commit.
There is a kernel fix from upstream [1], they changed the rsize / wsize
to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's
default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have
its own linux-yocto kernel branch, so apply this change might cause
regression with other platforms which share branch with qemuppc64.
So, we added an extra option for nfs rootfs, and set the qemuppc64 default
r/w size to 524288 to line up with the kernel fix[1].
Yocto did a similar thing in the distant past[2] - prior to boot-arg
adjustments existing - by allowing a Kconfig to set the defaults on
nfsboot, in order to work around hardware limitations.
Reference:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf
[2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95
(From OE-Core rev: 14a81556ff1be326647e654424c8f1bf9d0db912)
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>
This extra options to be appended to the nfs rootfs options in kernel
boot arg.
Example config with qemuppc64 in machine config:
add r/w size in the nfs rootfs extra option:
QB_NFSROOTFS_EXTRA_OPT = "wsize=524288,rsize=524288"
re-build and runqemu with nfs again, we can observe the kernel command
line added our defined value in QB_NFSROOTFS_EXTRA_OPT:
Kernel command line: root=/dev/nfs nfsroot=10.0.2.2:/home/xchen5/testing/build/tmp-glibc/deploy/images/qemuppc64/testnfs,nfsvers=3,port=3049,tcp,mountport=3048,wsize=524288,rsize=524288 rw mem=256M ip=dhcp console=hvc0 console=hvc0 nohugevmalloc
(From OE-Core rev: 43a97f5bf3f90c5c1fd603f7dca2b3db2c0e3040)
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>
The default return value from subprocess.check_output is an encoded byte.
The applied fix will decode the value to a string.
(From OE-Core rev: 046769fa952a511865c416b80d10af6287147fb7)
Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the 6.1 kernel we've seen reproducibility/determinism issues where the kernel
seems to rebuild headers referencing the hostname or local user. kernel-devsrc
building after the kernel seemed to trigger it in some cases.
Moving the definitions to the bbclass used by all the kernel recipe code including
kernel-devsrc seems to be the best way to ensure this doesn't happen.
(From OE-Core rev: 60681baa97daf4f3856453c34d6be08b6771a81b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe is needed to build softhsm (in meta-oe) in with p11-kit
support, which is useful when multiple PKCS#11 modules need to be used.
(From OE-Core rev: 4942a42d5a071b283fe49047dcb4fee2c96422e8)
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If having devtool modified a recipe and then updated the crate versions,
e.g., by doing a git bisect, running the update_crates task needs to
always update the .inc file even if the bitbake metadata has not
changed.
(From OE-Core rev: 137d290ac1f7516a509fc9d264489e51c3004d5d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch to fix the tools-only_defconfig error has landed in
U-Boot upstream.
Update the Upstream-Status accordingly.
(From OE-Core rev: f0facfbebcc5e4d74f70740c920df4c7c0824086)
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The buildtools-tarball includes a native sysroot with .pc files, and
in the case of buildtools-extended-tarball a pkg-config binary too.
If we're using the host pkg-config then it doesn't know to search in the
native sysroot. If we're using our pkg-config then it searches in the
build-time prefix and not the actual SDK installation location.
Neither of these are correct, so set PKG_CONFIG_LIBDIR to search:
- The native sysroot
- The host pkg-config's default search path, if present
- Falling back to /usr/lib/pkgconfig, if not
In an ideal world this would be handled by the generic toolchain script,
but that is slightly more involved.
[ YOCTO #15007 ]
(From OE-Core rev: 8f768a3f4c7ff477e994d60800e5a1b83891615a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-selftest efibootpartition.GenericEFITest.test_boot_efi was failing for 6.1 kernels with:
| ERROR: _exec_cmd: export PATH=[...] mcopy -i [...]/rootfs_boot.1.vfat -s [...]/rootfs1/* ::/ returned '1' instead of 0
| output: Disk full
I believe we hit a file boundary size and having "0" overhead in the image meant
the files couldn't be installed. Allow a small amount of overhead to avoid
the error.
(From OE-Core rev: 16e0b8a8fc36f5525b1801888851958f0dbe84c2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In recent kernel versions the string "Linux" moved to a header,
'include/linux/uts.h' instead of init/version.c. Allow the test
to work with both situations.
(From OE-Core rev: c15c59c88d229e35eeac1ed948c84168633e7cb1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is for breaking circular dependency in following condition:
After enabling PACKAGECONFIG nghttp2 for curl, the dependency chain is:
curl-native -> nghttp2-native -> cmake-native -> curl-native.
So change to use internal cmcurl library to fix this. And as using
system curl library before, disable nghttp2 and use system openssl
library for cmcurl.
(From OE-Core rev: f9a5f9fdb69bb61242dc65ed83704f727491ecca)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bb.utils.export_proxies() is a poor-man's alternative for the
environment setup code in bb/fetch2, but it's used in several places
where recipes want to download manually (such as cve-update-db-native).
Notably, export_proxies() doesn't pass on the SSL certificate paths from
the original environment, so if SSL_CERT_FILE needs to be set (for
example, in a buildtools environment) then proxies work but SSL doesn't.
In an ideal world export_proxies and the same logic in fetch2 would
merge, but until then we can add the SSL_CERT_ variables and duplicate
the basic logic: check the datastore first and then the original
environment for variables.
Also remove the return value as nothing ever checked it.
[ YOCTO #15000 ]
(Bitbake rev: c19035e8e71c419c5688a86bfc9c946c96f638e8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the codeparser cache is set from CACHE, which is typically in
bitbake.conf which means we can't read/write any cache until it is found/read.
We may well have python expressions to parse before that happens.
The net result is suboptimal functioning of the codeparser cache since it will
often be invalidated by data that is never written.
This patch changes the codeparser and filechecksum caches to use BB_CACHE as
their setting and defaults it to ${TOPDIR}/cache.
The patch doesn't change where the "persistent" data such as prserver and
hash-equiavalance resides (PERSISTENT_DIR) or where the metadata parsing
cache resists (still currently CACHE). I've left those for a later patch.
The patch does ensure data parsed by the core datastore parsing calls is
written back since this is now much more useful after this change.
(Bitbake rev: ee89ade5b5a4cf9c53f336d8b800e06fbe436628)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Update to latest langdale 4.1.2 and kirkstone 4.0.6
* Re-instate dunfell and update to 3.1.22
- drop comments about bitbake crash
(Bitbake rev: f90c45df5cf4640e0714fde13e311db3327f9fd4)
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>
bitbake-getvar does not have a way to silence bitbake
server's logger and that makes the tool hard to use for
text processing. This is especially true when one wants to
get a bitbake value to be piped to some other utility and
instead we get uncontrolled logging messages or warnings
together with bitbake's variable value.
Example without quiet:
bitbake-getvar --value MACHINE
NOTE: Starting bitbake server...
qemux86-64
With quiet:
bitbake-getvar --value MACHINE --quiet
qemux86-64
(Bitbake rev: af354e975d0b4c26d0e91e3c82946b093bc11b45)
Signed-off-by: Paulo Neves <ptsneves@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is really no change since it is currently the default in gcc but
making it explicit matches the other SDKMACHINE configs and means if gcc
ever changes, or we switch compilers, the flag is present. It also makes
it clear from the config which tuning is in use.
(From OE-Core rev: 21c012659a36835837b21b7a2bf1f12428aa16a4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes that use native BBCLASSEXTEND and set PACKAGES_DYNAMIC will
currently see PREFERRED_PROVIDER warnings. Some recipes work around this
but lets fix the core code to handle remapping PACKAGES_DYNAMIC correctly
so the workarounds aren't necessary any more.
(From OE-Core rev: e74b416231610ce3962e5b7bc21bd382579802ad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This stops the codeparser cache changing ever time a new commit is
added to the main repository.
(From OE-Core rev: f77b9f983395c648fddc96f0d6c8ebd6d52056d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
