babeltrace2-ptest was referencing the host's python version in it's
makefiles. Whilst this could be fixed, its easier to correct the
python version being found to the target one which works much
more effectively and solves the issue.
(From OE-Core rev: 559f16d2fef4f8b04a9db1104b4a5b63f7876c68)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
diffoscope uses libmagic and it was searching in file-native's sysroot
for the magic file. Wrap it and set MAGIC in the environment to
ensure the file is found correctly and avoid build failures.
(From OE-Core rev: 3488a8316891829892bd41a1caacaeeef73da7ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of just providing local.conf info, add layer names and their
revisions with bitbake version information into error report
makes it easier to understand and reproduce failed build.
[YOCTO #9700]
(From OE-Core rev: a5afd7b1857c0012ab6e3d8bbafa67a96ff9e9e0)
Signed-off-by: Milan Shah <mshah@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Das U-Boot 2021.4-rc1 has the following commit:
commit 3f04db891a353f4b127ed57279279f851c6b4917
Author: Simon Glass <sjg@chromium.org>
Date: Mon Feb 15 17:08:12 2021 -0700
image: Check for unit addresses in FITs
Using unit addresses in a FIT is a security risk. Add a check for
this and disallow it.
CVE-2021-27138
Adjust the kernel-fitimage.bbclass accordingly to not use unit
addresses. This changte is required before we can bump U-Boot to 2021.4.
(From OE-Core rev: 6047be9f8f0f5d616fda11d83b682c1b8aeaa0ae)
Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Even in grub-efi platforms we need to build grub for the the common
tools. On x86 this isn't a problem because grub builds legacy boot and
grub-efi builds EFI, but on aarch64 there is no legacy boot supported by
grub.
To ensure that the common tools are built the grub recipe also builds
EFI binaries, but this now means that grub and grub-efi ship the same
binaries.
oe-core 933286 fixed this conflict by deleting the binaries from
grub-efi and putting the aarch64 modules into grub-common (relying on
dependencies to pull grub-common in). This seems backwards: grub-efi no
longer contains the binaries and they're in different packages on arm or
x86. Also, SDK generation is broken as the grub package itself is now
empty as the binaries are in grub-common.
Resolve all of these issues by reversing the logic: grub-efi is the
package which holds the EFI binaries on all platforms. grub only builds
for EFI on aarch64 as a way to build the common binaries, so delete them
in that recipe to avoid conflicts. And finally as the grub recipe is
empty on aarch64 but needed by dependencies, set ALLOW_EMPTY.
(From OE-Core rev: 801c10b33eb2074677d46b361e46f47b693b573a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure the python interpreter is "#!/usr/bin/env python3" for
nativesdk to avoid the shebang path exceeding the limit when install
the sdk under the directory with long path.
Before:
$ cd ${target_sdk_dir}
$ vi ./sysroots/x86_64-oesdk-linux/usr/bin/2to3
#!${target_sdk_dir}/sysroots/${SDK_SYS}/usr/bin/python3.9
[snip]
After:
$ cd ${target_sdk_dir}
$ vi ./sysroots/x86_64-oesdk-linux/usr/bin/2to3
#!/usr/bin/env python3
[snip]
(From OE-Core rev: a748e6098fa7d2ff594319937c7e0cf97700e83a)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to my tests this incorrect symbols resolution at runtime no
longer happens. Ubuntu is still carrying the patch but also probably
doesn't need to, they are also on a much older version. It sounds
like there was once a linkage bug somewhere which has likely been
resolved since.
Drop the patch as it doesn't seem needed anymore. If it were a real
issue it should be submitted upstream too, the status is incorrect.
(From OE-Core rev: 02f36ed515afed550dfcd986977ce2106dee556a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch was submitted and merged upstream.
(From OE-Core rev: 871bce0703ca9d14e5c44f6ee0b66fcb13cfb630)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By using the python3targetconfig class we can drop the existing python
patch and the extra make parameters.
(From OE-Core rev: 3bbebc39235f50af4d66e3284b67c1491d2c93f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
configure falls back to inspecting the host#s /etc/group for the
nobody/nogroup naming. Pass the correct value to configure to
ensure host differences don't sneak in.
(From OE-Core rev: e5f809068b32df32e506f3067cd6086195e03f12)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes sure that we can compile glibc for powerp9 based machines
irrespective of endianness or bitness
(From OE-Core rev: 6201018650fe8966b99860bbda24c5903e7d7a60)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl is configured to use /lib and /usr/lib for ppc64 unlike glibc where
it is expected to have libs in /lib64 and /usr/lib64
(From OE-Core rev: 998d15a86282d9cf57fbd0a4eb76a56b9938a348)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ppc64le should go above ppc64 in checks otherwise it gets subsumed
wrongly with ppc64 check
(From OE-Core rev: 126ecfe0d2ce65b2d2cf5598612e60bad7b3302e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
loader is installed into /lib and ${base_libdir} may not be always
pointing to /lib, while here we want to create the directory where ldso
will reside
(From OE-Core rev: 76795b5a4452b531c342df2c8a3bbb264cc8a8d2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On ppc64le 'le' should be appended to ldso name
(From OE-Core rev: dd221cdc8630a5adba1f87ff7a237021e9a95548)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using nographic, explicitly disabling vga is needed some cases
since some qemu firmware (OpenFirmware ) defaults to std vga, and
when vga is enabled then it disables output to serial and redirects
that to vga which is by design, hwoever we expect the console output
to go to serial when using nographic, therefore its important to
disable vga with nographic especially on qemu based ppc platforms
(From OE-Core rev: eabbdb3c4f78ab23348a6b988f59d9d98b5e2c7c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The comment above the importd config states curl, which does not
exist in PACKAGECONFIG. Adding it results in the following error
(and then misleading compilation failures):
WARNING: systemd-1_244.5-r0 do_configure: QA Issue: systemd: invalid PACKAGECONFIG: curl [invalid-packageconfig]
Support for curl is currently enabled through journal-upload:
PACKAGECONFIG[journal-upload] = "-Dlibcurl=true,-Dlibcurl=false,curl"
While it might be more appropriate to deprecate "journal-upload"
in favor of a "curl" PACKAGECONFIG entry, simply fix the importd
comment for now by stating upload-journal instead of curl.
(From OE-Core rev: e6a0bced605da58ff43ff06ea6a1d67e84c98d91)
Signed-off-by: Vivien Didelot <vdidelot@pbsc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License changed as there was additional copyright information added
but the underlying license did not change.
(From OE-Core rev: 97f5846586076c20289a2a43c7ddfa610a6aa5d9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The license file dropped the APL-2 pieces but this wasn't in LICENSE
in the first place, no code seemed to refer to it so no change was
needed.
(From OE-Core rev: f31d3d8999ce314832012324ce8bebf42dcfb372)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License file had a number of new additions for new firmware but no
new licenses that didn't already exist.
(From OE-Core rev: eab46e65feae24311f0ee0cd05b7ebb2e3b07363)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Match SPDX licence name changes in OE-Core.
(From meta-yocto rev: 4acb5d2a9e77b8f426fa2370a9a71b9df8c7c3e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
5f7fdf7b2d ("bitbake: event: Prevent bitbake from executing event
handler for wrong multiconfig target") broke multiconfig builds contain
a hyphen, since it's attempt to use the multiconfig as part of a
function name and python functions are not allowed to contain a hyphen.
Rework the bitbake multiconfig test to test a multiconfig with a hyphen
and one with an underscore to validate this doesn't break in the future.
(Bitbake rev: c3168df330a4563cbd03ba74de55a22217d823ed)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit bebef58b21bdff7a3ee1fa2449b7df19144f26fd introduced forcing
parser shutdown as default in case of build abort.
In this case bitbake sometimes hangs after facing error during parsing,
waiting for child processes to finish. Killing it then will spawn zombie
processes.
Thus we force the shutdown after catching an exception.
(Bitbake rev: 915330e1dbae1ee8fd9a0358decf2c294f771961)
Signed-off-by: Jan Brzezanski <jan.brzezanski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If no eligible providers are found then an integer zero is returned.
This causes the following error, in two possible places in taskdata.py,
when the return value is used in a list comprehension:
[snip]
eligible = [p for p in eligible if not p in self.failed_fns]
TypeError: 'int' object is not iterable
[\snip]
Fix by returning the variable eligible itself, of type list.
(Bitbake rev: 217c4b436b588a6a47aeaddf61531711ad3fca67)
Signed-off-by: Charlie Davies <charles.davies@whitetree.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-build-sys-do-not-build-plymouth-ctrl.c-w-disabled-pl.patch
0001-hwclock-do-not-assume-__NR_settimeofday_time32.patch
removed since they are included in 2.36.2
(From OE-Core rev: 4db0babf6a69a90df14363103f5f6b643f208b12)
Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wordsize.h should be the same under arm and aarch64, othersise the
following error happens:
"file /usr/include/bits/wordsize.h conflicts between attempted installs of lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
(From OE-Core rev: cf487df7d58ea89fcef5c4bc30c2ca1ceded9508)
Signed-off-by: Zheng Ruoqin <zhengrq.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix build error under multilib as following:
"file /usr/include/bits/struct_stat.h conflicts between attempted installs of lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
(From OE-Core rev: 163ec51715e939fe9ff3f87c2af46a77e1a8edea)
Signed-off-by: Zheng Ruoqin <zhengrq.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All tests are installed, but only what `make check`
runs is run, so currently that's 1 test named `check-all`
`libcheck` needs to be present for ./configure to generate
the check* tests.
An issue asking about upstream testing strategy is opened at
https://github.com/thom311/libnl/issues/270
(From OE-Core rev: 23a785a373f76a24f4f7dd867522ce296cbf30f3)
Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the separate of the "-only" and "-or-later" licenses, we need to
update the tests to match the messages now given in the output.
Also use a mix of canonicalised and non-canonlised names in the
reference recipes to help test those cases and ensure coverage.
(From OE-Core rev: b7f38af7ac9449178c603c5349808b8c0dd84d35)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code internally correctly handles canonicalisation of these license
fields, we shouldn't call it manually. The issue is that the fields can
contain wildcards and GPLv3* means something quite different to GPLv3-only*.
(From OE-Core rev: 957f48ce78ad1865653e8b8f25909a65ba8fc535)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where a user adds "GPLv3" to INCOMPATIBLE_LICENSE they almost certainly
mean both GPLv3-only and GPLv3-or-later. Update the code to handle this
correctly.
(From OE-Core rev: 08cbf17485b6443a6118acfac8200eb6c61445a3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GPLv2 and GPLv2+ are two difference licenses with different meanings
and we can't just pretend they're the same thing. Change the code
to treat them separately.
(From OE-Core rev: d1baf74ac92fe0c8c32dff101fd77d77f70fd583)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
