This is specific to Git-for-Windows.
(From OE-Core rev: c8849af809e0213d43e18e5d01067eeeb61b330d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes CVE-2022-41903 and CVE-2022-23521.
(From OE-Core rev: 8395d2512c5335635fff3ce2043ac71fe1948c42)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This does not actually guarantee that the child runqemu process has completely exited:
poll() may return prematurely while the SIGTERM handler in runqemu is still running.
This thwarts the rest of the processing, and may terminate the handler before
it completes.
Use Popen.communicate() instead: this is what python documentation recommends as well:
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
(From OE-Core rev: cd3e55606c427287f37585c5d7cde936471e52f4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in overcoming a problem when using scons with ccache enabled.
When commands get longer, then it resorts to using response files to do
the operations e.g. @/tmp/tmp96j6icra.lnk when this response file is
inboked by compiler it works ok, however, this does not when ccache is
used to invoke the complilation. We see errors e.g.
ccache @/tmp/tmppsyij_0v.lnk
ccache: error: execute_noreturn of @/tmp/tmppsyij_0v.lnk failed: No such file or directory
Using MAXLINELENGTH setting ensures that we can use ARG_MAX to extend
the length of commandline and hence avoid using response files. This
issue is also reported in mongodb [1]
[1] https://jira.mongodb.org/browse/SERVER-38389
(From OE-Core rev: 29558f6218f4676b459f2c78f82d245339d51c8c)
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>
python bindings need cython to build, moreover they have been removed
from future releases upstream nghttp2 [1]
This ensures consistent builds as it does not need cython which was
being used from build host if it is installed. With some distros e.g.
archlinux it caused conflicts with python from python-native
[1] b4cb3b0090
(From OE-Core rev: ce59be9d48fa679ad54b70368d8a76daadbe88ba)
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>
Disable ZStd to avoid needing libzstd in llvm (mirrors zlib disable).
Generate complete list of rust-snapshot artefacts from src/stage0.json.
Drop clippy-driver reproducibility change as the code is gone from
upstream.
Release notes:
https://releases.rs/docs/1.67.0/
License-Update: Unicode-TOU text added (already in our license string)
(From OE-Core rev: 4900e0c5cb8a092a1d77d4f26249afa59b241da6)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The main reason for this is an issue with latest libtiff update that causes
gtk4-native configure to fail in finding libtiff (while it just builds
fine for target).
By comparing libtiff-4.pc for native and target it turned out, that
it links for native with zstd and libdeflate. Probably because those libs
were found on my host system.
Adding PACKAGECONFIGS for the libs prevents us from taking them from the host.
(From OE-Core rev: ca2e2035b9d81a230a1a63f51b1300418e9b9ca6)
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>
- update to next (un)stable version 1.36.0
- refresh defconfig
- disable new applets (tree, tsort, seedrng)
- use hw-accel for sha1/256 sums when available
- remove and refresh already merged patches
(From OE-Core rev: 2e9989a8f8b5b93476e551475df010add32aac31)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
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>
Deleting data files whilst bitbake is running isn't a great idea.
Make sure memory resident bitbake is stopped if present and make
the file deletions a little more specific and safer too while we're
here.
Note: The cache directory layout is different on older releases (some
are split level) so this won't be a direct backport to some.
(From OE-Core rev: fa3f1f67abae1d90bede2e98bf7293603fd1307c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Rebased fix-rs6000-crt0.patch
- Patch fix_makefile_include_arm_h.patch is no longer required, the newlib
header dependency has been fixed upstream at 26f9cfd7
- LICENSE checksum change due to:
- Adding SPDX identifier
- Deleted Phoenix Systems from License and updated each licenses
numbers accordingly.
- Add a dummy limits.h header, to make the improved preprocessor
checks happy during configure.
- Add a patch for libgloss to maintain current behavior of TCLIBC=newlib
by making libgloss DEPEND on newlib and use its installed headers.
- Switch to git fetcher to simplify fetching the sources and avoid future
issues due to the way newlib release snapshots were being published.
(From OE-Core rev: 1c9cbb27dfe37ca4574c4285fb03ce394dee5ed1)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bug this was intended to find has been resolved, so we don't need
this extra noise in the logs.
This reverts commit bd1edfa3d5.
(From OE-Core rev: 54ae53ef3e4ad51fc9a01155588b62f29c994742)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had a couple of reports of recipes expecting to be able to call
split("-") on PN. There isn't any real harm in adding a dash to the dummy
PN value to avoid these errors.
(From OE-Core rev: 10e140d98790ce28b440b8e8697a4311658fe4df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The definitions in linux-kernel-base are needed to ensure the generated headers
are consistent. This was a small step that was missing from the previous
changes to linux-kernel-base as both kernel-devsrc and make-mod-scripts
need this information defined consistently.
(From OE-Core rev: 0d79d4883f924cef0d0ba361506ad75d441b9721)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch that allows to do so has not been accepted upstream, and wasn't correctly
working as it was running a native executable (gdk-pixbuf-query-loaders) with target .so plugins.
On the other hand, out of 20+ (currently 23) tests only three require
running binaries at build time to produce special test-specific input data:
cve-2015-4491
pixbuf-pixdata
pixbuf-resource
So let's simply omit these from the build: this can be done with a far
less invasive patch which has a chance of being accepted upstream.
gdk-pixbuf-print-mime-types is no longer installed
(the replaced patch was doing that).
(From OE-Core rev: 0d926508e75095eb446699b612729d0243eacc91)
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>
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>
