Add some information about some further kernel CVEs which don't apply for
either linux-yocto or don't apply for linux-yocto 6.1.
(From OE-Core rev: 85c1713bf0c01c68558bfba38edcc005c1ebb1c9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ignore CVE-2022-38457 & CVE-2022-40133 as they looks patched in our 6.1
branch.
I've asked the NVD to add the commit as the patch for these CVEs, but in
the meantime, other sources seem to agree that the commit fixes these
CVEs (and I concur).
(From OE-Core rev: 990d1cbb1628577bd159e8266fa15976f1f17062)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Fix the location of the target for supported distributions
- Improve the name of this target
(From yocto-docs rev: 40f0cf9302b9f0ce01a1270977644b1b2fdfc650)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVEs CVE-2023-0179, CVE-2023-1079 and CVE-2023-1513 are patched in our
kernels but appear as active because the NVD database is not up to date.
(From OE-Core rev: ae1e7999a06c56c6f752413296b8f6b505475f8b)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Reviewed-by: Frank WOLFF <frank.wolff@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to signedness, the checksum is not computed when filesize is bigger
a 2GB. Pick a fix for this problem from CPIO ML, where the fix has been
posted for 5 years. Since CPIO upstream is effectively unresponsive and
any and all attempts to communicate with the maintainer and get the fix
applied upstream failed, add the fix here instead.
(From OE-Core rev: bfff138af4bdd356ac66571e6ad91c1a5599b935)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible to call exported tests with --target-ip set to ":22"
where IP address is not set at all. Detect this case and fail the test
instead of calling ping without an IP address.
(From OE-Core rev: 17c995c53775b8cee279ca4ced916092067e1195)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is to announce grep-3.10, a stable release,
fixing a bug with -P and \d. TL;DR, grep-3.9 would do this:
$ LC_ALL=en_US.UTF-8 grep -P '\d' <<< ٠١٢٣٤٥٦٧٨٩
٠١٢٣٤٥٦٧٨٩
It should print nothing, like it has always done.
For more detail, see https://lists.gnu.org/r/bug-grep/2023-03/msg00005.html
Thanks to Paul Eggert for catching the \D variant and to Bruno Haible
for assiduously tending gnulib and for testing grep on so many
different systems.
There have been 12 commits by 2 people in the 17 days since 3.9.
(From OE-Core rev: 7ac3bcf228ceb4b56f82c65941b95a276d7d3b95)
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
COPYING files had 2 updates w/o affecting licensing:
* URLs to gnu.org and fsf.org switched to https
* Clarifying licensing of liblzma Doxygen-generated docs - details below
5.4.2 (2023-03-18)
* All fixes from 5.2.11 that were not included in 5.4.1.
* If xz is built with support for the Capsicum sandbox but running
in an environment that doesn't support Capsicum, xz now runs
normally without sandboxing instead of exiting with an error.
* liblzma:
- Documentation was updated to improve the style, consistency,
and completeness of the liblzma API headers.
- The Doxygen-generated HTML documentation for the liblzma API
header files is now included in the source release and is
installed as part of "make install". All JavaScript is
removed to simplify license compliance and to reduce the
install size.
- Fixed a minor bug in lzma_str_from_filters() that produced
too many filters in the output string instead of reporting
an error if the input array had more than four filters. This
bug did not affect xz.
* Build systems:
- autogen.sh now invokes the doxygen tool via the new wrapper
script doxygen/update-doxygen, unless the command line option
--no-doxygen is used.
- Added microlzma_encoder.c and microlzma_decoder.c to the
VS project files for Windows and to the CMake build. These
should have been included in 5.3.2alpha.
* Tests:
- Added a test to the CMake build that was forgotten in the
previous release.
- Added and refactored a few tests.
* Translations:
- Updated the Brazilian Portuguese translation.
- Added Brazilian Portuguese man page translation.
(From OE-Core rev: 0331fac93570b8e2960ac94b2a6a7eb71cb1a1d0)
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* if you don't have QEMU_USE_KVM in local.conf it fails with:
2023-03-12 18:06:29,591 - oe-selftest - DEBUG - Checking if qemux86-64 is not this MACHINE
2023-03-12 18:06:29,594 - oe-selftest - INFO - ... ERROR
2023-03-12 18:06:29,594 - oe-selftest - INFO - Traceback (most recent call last):
File "/OE/build/poky/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/poky/meta/lib/oeqa/selftest/cases/efibootpartition.py", line 18, in test_boot_efi
if oe.types.qemu_use_kvm(self.td['QEMU_USE_KVM'], self.td["TARGET_ARCH"]):
~~~~~~~^^^^^^^^^^^^^^^^
KeyError: 'QEMU_USE_KVM'
[YOCTO #12937]
(From OE-Core rev: 7c32ca2f91beb98769c89470b37f06cb4b99aebb)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the recent change to the crate fetcher, which automatically sets
the name to for each crate to be versioned, there is no longer a need to
explicitly set the name= parameter for each URI. This also results in
generated files that are compatible with the crate fetcher in Kirkstone
and Langdale.
(From OE-Core rev: eb272afcd9a12ce2b2f43436b3f84f52cb6cdfb7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is common for rust packages to depend on different versions of the
same crate. E.g.
| crate://crates.io/windows_x86_64_msvc/0.42.2 \
| crate://crates.io/windows_x86_64_msvc/0.48.0 \
Identification only by the plain crate name makes the sha256sum
ambiguous
| SRC_URI[windows_x86_64_msvc.sha256sum] = "9aec5da331524158c6d1a4ac0ab1541149c0b9505fde06423b02f5ef0106b9f0"
| SRC_URI[windows_x86_64_msvc.sha256sum] = "1a515f5799fe4961cb532f983ce2b23082366b898e52ffbce459c86f67c8378a"
and requires lot of manual work to fix the SRC_URI list.
Making the 'name' property unique by appending the version allows
direct copy & paste of reported sha256sum errors to complete the
crates list.
(Bitbake rev: ae2efb05196f9e29ef56ad9a84e2eae5fbdd8030)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
hwclock.sh had default update-rc parameters which made it run after
other tasks that work with the clock such as connman. This causes a
time obtained by NTP to be clobbered by a potentially incorrect time
in the RTC.
Provide non-default INITSCRIPT_PARAMS to have hwclock.sh run during
the rc startup before runlevel initscripts start.
(From OE-Core rev: 3012bac35ada9a9f66d9e6e2fecaee09527b9d44)
Signed-off-by: Chris Elledge <celledge@siteworx.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since bitbake commit 81a58647b2f4fc0a2589b2978fc9d81b2bfe6aec
[bitbake: build: Make python output print to stdout when running with
-v (verbose)] we no longer need to comment out the python stdout
checks.
(From OE-Core rev: 67886a8473c511c8ab3db2e4587cc5a070979d11)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qemu build system enables the 'log' trace backend by default, if no
explicit choice was made with '--enable-trace-backend=CHOICE'.
However, the qemu recipe uses the following PACKAGECONFIG line:
PACKAGECONFIG[ust] = "--enable-trace-backend=ust,--enable-trace-backend=nop,lttng-ust,"
which means that the 'nop' trace backend will be explicitly selected if the
'ust' feature is not enabled. The 'nop' backend removes almost all trace
points at compile time, and thus basically means 'disable tracing'.
To retain the default trace backend if 'ust' is not enabled, the above
PACKAGECONFIG line should either explicitly fall back to the 'log' backend,
or not provide any value for the 'disabled' case. This commit chooses the
latter to not make any assumption about the upstream default.
(From OE-Core rev: c31396a30dcf17ab23ff4dd5943eef5fba20cba6)
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'#line' directives written by qemu's tracetool makes the 'debug' package not
reproducible due to absolute paths. Apply a patch to use a relative path
instead.
(From OE-Core rev: 85e30c507b63fa9126887dc6435d1ee6e23bd887)
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple CVEs are patched in kernel but appear as active because the NVD
database is not up to date.
In common file cve-extra-exclusion.inc, CVEs are ignored if and only if
all versions of kernel used are patched.
In cve-exclusion_6.1.inc, only ignore CVEs that are patched in v6.1,
and not patched in v5.15.
Recipes of version 6.1 should include this file.
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
(From OE-Core rev: 5feb065f1b1aaf218f71cc9d31a9251b139b9442)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the previous commit I somehow mixed up and used an incorrect CVE number.
Use the correct one.
(From OE-Core rev: b3e2729f686ff6e16e11590bcd701c057ae5f1e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Take a patch submitted upstream for the issue while upstream decide what
to do. We don't use thunderbird integration so this isn't an issue for us.
(From OE-Core rev: b85b7714a44caa70beb2f115483ee52745aa1b97)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've increased the minimum GCC version to 8.0[1] so update the
documentation to match.
[1] sanity.bbclass: Update minimum gcc version to 8.0
(From yocto-docs rev: c74254fa7406c76b26e47b968685115699f95c55)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but vte has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 686e0cb93f9f6ef663243e62c7a8cc43ca1dcd3a)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of only display the first and stop.
For recipe (crago based) that can contains several artifacts
to fetch with their checksum, it will particularly handy
to display all of missing one.
An example of error message would be
NOTE: Executing Tasks
ERROR: zvariant-3.12.0-r0 do_fetch: Missing SRC_URI checksum, please add those to the recipe:
SRC_URI[anyhow-1.0.70.sha256sum] = "7de8ce5e0f9f8d88245311066a578d72b7af3e7088f32783804676302df237e4"
SRC_URI[chrono-0.4.24.sha256sum] = "4e3c5919066adf22df73762e50cffcde3a758f2a848b113b586d1f86728b673b"
SRC_URI[serde-1.0.158.sha256sum] = "771d4d9c4163ee138805e12c710dd365e4f44be8be0503cb1bb9eb989425d9c9"
SRC_URI[system-deps-1.3.2.sha256sum] = "0f3ecc17269a19353b3558b313bba738b25d82993e30d62a18406a24aba4649b"
ERROR: zvariant-3.12.0-r0 do_fetch: Bitbake Fetcher Error: BBFetchException('There was some missing checksums in the recipe')
ERROR: Logfile of failure stored in: /home/jenkins/yocto-poky-master/poky/build/tmp/work/core2-64-poky-linux/zvariant/3.12.0-r0/temp/log.do_fetch.1025
ERROR: Task (/home/jenkins/yocto-poky-master/poky/meta-selftest/recipes-extended/zvariant/zvariant_3.12.0.bb:do_fetch) failed with exit code '1'
(Bitbake rev: dafa07c080e05975b6319b5adf78a9691c6b6643)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An upcoming change will simplify the setuptools3-base FILES assignments,
which means this recipe needs to package a library explicitly.
(From OE-Core rev: bab2e8c76453cf9982af936f20c6b22cc2237ba7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If these files exist they should be packaged into PN-dev, and are with
the default FILES:${PN}-dev.
(From OE-Core rev: 738434bf567d25de692cd145156263eea1a5de13)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simply inheriting setuptools3-base should put everything in $libdir in
PN, and there's no need to replicate the pkgconfig packaging rules as
those are the defaults.
(From OE-Core rev: 56a32e31d4fdfb908f0edf513d21bc0f2b8c721e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but libnotify has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 63cc22caf4dfcde1d7a3a8410559bb227ed95c33)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, gettext-native and
glib-2.0-native dependencies are not pulled in, which causes failures
in do_compile due to missing xgettext and gdbus-codegen.
(From OE-Core rev: c9e4c3d437ba7cadb87bc30b85f602b8551a0e17)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native
and gobject-introspection package dependencies are not pulled in
but gconf has a hard dependency on them (do_configure fails due to
missing introspection.m4 file and glib-gettextize).
(From OE-Core rev: d87bc67fde3c8bc6068cb67708953ce88ac31e3f)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When g-i feature is disabled, the gobject-introspection package
dependency is not pulled in but pygobject has a hard dependency on it.
(From OE-Core rev: 7fae697c6889e17dd47415808a7173670b507047)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an option to enable/disable build of graphene-gobject. When
enabled, add glib dependency (not pulled in implicitly if
the gobject-introspection feature is disabled).
Default is to enable gobject-types so that graphene-gobject is built
(dependency of gtk4).
(From OE-Core rev: b82781498cda67f4797de5b8b7c2b90a275a72e1)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the report-error catch Nothing PROVIDES error and then
we can check it directly via error report web.
(From OE-Core rev: a57d8f82b83554c821a83eacc02f9c73b263ff02)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rebase patches; one of the vendored crossbeam versions
has been removed upstream, and so crossbeam_atomic.patch
is adjusted accordingly.
Replace getrandom-open64.patch with a backport.
(From OE-Core rev: f5accb4fae49342cbec21718ae7a427615bfcedd)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it triggers a rebuild of llvm-dependent rust pieces every time rust_runx is called,
lengthening the builds without need.
(From OE-Core rev: aca6b29b508175da9f213b1c6dba5d02a15b8287)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream does not actually use or test it this way; if the goal
is to install items, then install target should be executed directly.
In particular, in latest rust release building stage 2 items has regressed
altogether (incorrect dependencies between rust-analyze tool and the
libs it needs) and no one noticed.
(From OE-Core rev: 7d805f9a9f6b5048308a37a2757d08cca40b1ff3)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* when searching for qemuboot.conf
* don't assume that IMAGE_LINK_NAME is always
<rootfs>-<machine> (with <rootfs>-<machine>.qemuboot.conf)
* runqemu: use IMAGE_LINK_NAME set by testimage.bbclass or query with bitbake -e
* testimage.bbclass was setting DEPLOY_DIR which I don't see used
anywhere else, so I assume it was supposed to be DEPLOY_DIR_IMAGE as mentioned
in corresponding runqemu code, do the same with IMAGE_LINK_NAME variable
* add virtual/kernel as bitbake -e target in run_bitbake_env to make
sure IMAGE_LINK_NAME is defined (kernel-artifact-names.bbclass inherits
image-artifact-names.bbclass as well)
* improve .qemuboot.conf search
1st search for file matching the rootfs and only when not found
try again with .rootfs suffix removed
[YOCTO #12937]
(From OE-Core rev: 716eb55bb963db7b02d985849cb025898aabc855)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
