There have been no specific patches on beaglebone branche for many years,
so I have decided to switch to using the base branch for this machine.
This approach eliminates the need to adjust the corresponding
SRCREV_machine and LINUX_VERSION with each stable kernel version bump.
(From meta-yocto rev: 1570badbf93511f370614c21ccd967af28549b2c)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a bbappend so that genericarm64 can use 6.12.x.
We explicitly set the SRCREV to incorporate some required config fixes
that have not been integrated into the oe-core recipe at this point in
time.
(From meta-yocto rev: 3b6d0ee17ac834a0521223eef67db3d39aaa1b78)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A buffer overflow vulnerability exists in GNU Binutils’ objdump utility
when processing tekhex format files. The vulnerability occurs in the
Binary File Descriptor (BFD) library’s tekhex parser during format identification.
Specifically, the issue manifests when attempting to read 8 bytes at an address
that precedes the global variable ‘_bfd_std_section’, resulting in an out-of-bounds read.
Backport a patch from upstream to fix CVE-2024-53589.
Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=e0323071916878e0634a6e24d8250e4faff67e88]
(From OE-Core rev: 7c9a9020d1e9204ba875ac10b20ab7ccabce82bc)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bugfix release for 8.11.0 regressions.
Solves CVE-2024-11053
Drop patch which was done differently upstream.
(From OE-Core rev: 57731284008c18eee566df3412eaf6d13a59d498)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Solves CVE-2024-9681
* refresh patch
* add patch for buildpaths issue
* add new options for ipfs and websockets, keep them configure as they
were previously configures
* drop notexists.pl from ptest install as it was removed and code was
integrated into the test framework in [1]
* add ptest dependency on perl-module-i18n-langinfo due to [2]
[1] 56183c1d6f
[2] 0b70b23ef4
(From OE-Core rev: 86dd3aca63248e1982c2d8c9dc68ae34a358cf8b)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit updates the warning to use a check for "trivially constructible" instead of
"trivially copyable." The original check was incorrect, as "trivially copyable" only applies
to types that can be copied trivially, whereas "trivially constructible" is the correct check
for types that can be trivially default-constructed.
This change ensures the warning is more accurate and aligns with the proper type traits.
LLVM accepted a similar fix:
https://github.com/llvm/llvm-project/issues/47355
PR c++/116731 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116731]
(From OE-Core rev: 7c9402953d1e4eed4bd4427171e96761812f7478)
Signed-off-by: Marek Polacek <polacek@redhat.com>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The KERNEL_CC variable usage was introduced by commit d2fcaeb153fd
("icecc: Don't generate recipe-sysroot symlinks at recipe-parsing time,
2018-12-20") and is set once a recipe pulls the kernel-arch.bbclass.
There are a few packages, e.g. u-boot, barebox, devicetree, perf which
pull this class and for such packages the get_cross_kernel_cc() return
None because icecc_is_kernel() fail.
Fix this for now by replacing the KERNEL_CC check with the
icecc_is_kernel() helper, which is also used by the
get_cross_kernel_cc().
That said it's still not very robust to determine a compiler based on
a variable or inherited class but at least it fixes the issue for now.
(From OE-Core rev: 5e3c6a6384fcdc4a2269172012caae14e5f327ca)
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since bitbake commit f24bbaaddb36 ("data: Add support for new
BB_HASH_CODEPARSER_VALS for cache optimisation") the icecc fails with [1]:
ERROR: /Yocto/poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb: no-pn NULL prefix
WARNING: /Yocto/poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb: Exception during build_dependencies for set_icecc_env
The reason for this is the bb.fatal() within the icecc_version().
icecc_version() is called during the "${@}" python variable expansion
while bitbake is running the build_dependencies() for the
set_icecc_env() function.
To avoid this behaviour set_icecc_env() should be converted into a
python function which gets called during task[prefuncs] [2], which is
done by this commit.
[1] https://lists.yoctoproject.org/g/yocto/topic/icecc_support_broken/103429714
[2] https://lists.openembedded.org/g/openembedded-core/topic/110009272
(From OE-Core rev: 444445c5793aaf831ff0293b62a000f8ab7d40bb)
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows fine-tuning local configurations with pre-frabricated
configuration snippets in a structured, controlled way. It's also
an important building block for bitbake-setup.
The tool requires that each fragment contains a one-line summary, and one or more
lines of description, as BB_CONF_FRAGMENT_SUMMARY style metadata.
There are three (and a half) operations (list/enable/disable/disable all), and here's the 'list' output:
alex@Zen2:/srv/storage/alex/yocto/build-64$ bitbake-config-build list-fragments
NOTE: Starting bitbake server...
Available fragments in selftest layer located in /srv/work/alex/poky/meta-selftest:
Enabled fragments:
selftest/test-fragment This is a configuration fragment intended for testing in oe-selftest context
Unused fragments:
selftest/more-fragments-here/test-another-fragment This is a second configuration fragment intended for testing in oe-selftest context
(From OE-Core rev: fdb611e13bd7aa00360d3a68e4818ef5f05c8944)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Please see the patch to bitbake for syntax and implementation details.
The path prefix to fragments is in its own variable so it doesn't have
to be hardcoded into tools.
(From OE-Core rev: 5bdbabd7b5d244a44c33065b04dd76dad76888a8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This alias is intended for managing specific local configs and it
is prompted by adding support for config fragments (in a separate
commit to oe-core); after some deliberation I concluded there should be
a separate tool, as bitbake-layers is already somewhat over-stuffed,
and this will give space for more build/conf/* operations in the future
that anyone can come up with (such as tweaking site-specific items
in site.conf etc.)
The alias completely reuses existing code via symlink and
the difference is in where it looks for plugins.
(Bitbake rev: ba90fe673aa87cb0cda9b2e465ebe2063551f527)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new listtasks() function (introduced in 185c4b) to avoid
accessing a private variable.
Also use assertSequenceEqual() directly as we don't really care about
the actual type returned, only that it's a sequence.
(Bitbake rev: 452289efc6d3608ceca321286fd5bf417a6e1bed)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was suggested that using flags in fragment content to
mark fragment-specific metadata (such as descriptions and
dependencies) is prone to quiet regressions when fragments
are renamed or moved, and it clutters the fragment content.
With this change allowed fragment metadata variables must
be explicitly listed in a variable that is given to addfragment
directive, and parser will add the flag containing the fragment name
to them.
(Bitbake rev: ed9a3ca9426500511feb77f41a146953dbfe9af7)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch from the Nokia/Scratchbox days[1] was obsoleted by qemu
improvements, specifically "linux-user: fake /proc/self/auxv"[2] which
was integrated into qemu 1.1.0 in 2011.
[1] If you're reading this and reminiscing I suggest standing up and
having a stretch, your back will thank you
[2] 257450ee59fd7e781cb4e2316ddc845c40b9fc42
(From OE-Core rev: b404dcbe9aeca9e82db929f021344ef3826726ab)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integrating the following commit(s) to linux-yocto/6.12:
1/1 [
Author: Ross Burton
Email: ross.burton@arm.com
Subject: arch/arm64/configs: remove CONFIG_SM_DISPCC_8650
Date: Thu, 12 Dec 2024 16:44:00 +0000
This option was removed from the Kconfig in in "clk: qcom: fold
dispcc-sm8650 info dispcc-sm8550"[1] but it was not removed from the
defconfig.
[1] 802b83205519e4253b873bef5c095b147cd69dad
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
(From OE-Core rev: bfed6922fc7ddf8bc30dc2ba5a3aae896d0a2de3)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-tiny and -rt were updated to a 6.12 specific inclusion, but
the -standard kernel was missed.
This commit also creates a 6.12 exclusion file, that is populated
with the last updates for the 6.10 kernel. Although it is no
longer updated automatically, that may change in the future and
it still provides value as a place to manually add CVE exclusions.
(From OE-Core rev: ab2e88ba876d954a2fc3eadee5ac860858340d5c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently pni-names PACKAGECONFIG option adds "mac" names policy if
selected, but nothing otherwise. In systemd Predictable Network Interface
Names are applied by default which leads to inconsistend behaviour.
One could think that pni-names in DISTRO_FEATURES would enable or disable
Predictable Network Interface Names, but currently if not present it's
only actively disabled for QEMU via kernel command line
(commit 9e9c33d51e40
("qemuboot/runqemu: Fix 6.2 and later kernel network device naming")).
It has no effect on the real HW. If the option is present, it merely adds
"mac" into default NamePolicy, which may or may not have observable
effects.
Make pni-names semantics more consistent by actively suppressing
Predictable Network Interface Names if the feature is not present.
(From OE-Core rev: 37b98bc93bc404823cc4bbf9039e4d114aac33fa)
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following recipes recently had their maintainership given up, so
list myself as maintainer for them:
- meson
- python3-markdown
- python3-smartypants
- python3-typogrify
(From OE-Core rev: caaa2d4345e9d9e9f1a313c5f4f1ed4e3539fea3)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has moved from autotools to meson, which requires a substantial
amount of tweaks to the recipe.
(From OE-Core rev: ae4824f4f6234884a245bce314d6305ad8eb982d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't access private variables, instead use the new bb.build.listtasks()
function (from bitbake 185c4b)
(From OE-Core rev: d31a7718c16bd26efd6e174cb5e97fb088aad4bd)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of iterating every datastore value by hand to find tasks, use
the new bb.build.listtasks() function (bitbake 185c4b)
(From OE-Core rev: 466c3ed0d01bc70caa29d5eb8bb99f7d0e6e710c)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was prompted by sstatetests.SStateHashSameSigs2.test_sstate_allarch_samesigs
where adwaita-icon-theme would fail due to new librsvg introducing
cargo-c-native into dependency path.
Rather than look into why is that, I simply converted the recipe
into the standard 'target + BBCLASSEXTEND' approach.
(From OE-Core rev: 80a2673a3081e623f30f25cc773ac9217e717958)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rpm2cpio has been deprecated upstream, so this prepares for its
eventual removal.
rpm2archive produces a tar archive which can be uncompressed
with tar executable from the host.
(From OE-Core rev: ed824d3fb23f0c89d8dfdacb2c4ef0b7c21a5144)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With this release, as expected, deprecated openpgp support
has been fully removed and replaced with sequoia:
https://github.com/rpm-software-management/rpm-sequoia/
Alas, it's written in rust, and has no recipe, so for now
signing rpm packages has to be disabled.
Remove package name parameter to %prep in source archiving, as it's
been dropped in the new rpm, and wasn't needed to begin with.
Drop 0001-perl-disable-auto-reqs.patch
(files removed upstream).
(From OE-Core rev: 8c15b4577d5e554cc2dd5adfb88b816894b05a9a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a race here where postinst relies on existence of
various files from other packages on the target rootfs to
operate properly, but doesn't ensure that it runs after all
of those packages have been installed. Adding dependencies
on those packages is not a solution as the recipe
is not supposed to bring them into rootfs, only make
adjustments if they are present.
This commit moves postinst execution to the first boot; another
solution would be to replace the whole recipe with ROOTFS_POSTPROCESS_COMMAND.
This was exposed with rpm 4.20 which rearranges the order
in which packages are installed, and exposes the issue.
(From OE-Core rev: e88f22da19a7f3f9bf23f2a607ffde6b5b1a3265)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During handle PACKAGECONFIG, DEPENDS/RDEPENDS/RRECOMMENDS is appended by
calling function appendVar according to the PACKAGECONFIG setting:
PACKAGECONFIG[f1] = "\
--with-f1, \
--without-f1, \
build-deps-for-f1, \
runtime-deps-for-f1, \
runtime-recommends-for-f1, \
packageconfig-conflicts-for-f1"
[snip of base.bbclass]
pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
if pkgconfigflags:
...
appendVar('DEPENDS', extradeps)
appendVar('RDEPENDS:${PN}', extrardeps)
appendVar('RRECOMMENDS:${PN}', extrarrecs)
...
[snip of base.bbclass]
After following commit in meta-oe,
[fe3ba7ac5c cryptsetup: demote udev runtime dependency to recommendation]
'udev lvm2' changed from RDEPENDS to RRECOMMENDS, but RRECOMMENDS is not
handled in this process, and causes following error:
$bitbake lib32-cryptsetup
ERROR: QA Issue: lib32-cryptsetup package lib32-cryptsetup - suspicious values 'udev lvm2' in RRECOMMENDS [multilib]
In layer openembedded-core, we do have very few recipes that have
runtime-recommends-for-f1 in PACKAGECONFIG setting, but f1 is not
enabled in PACKAGECONFIGS, so not report error when multilib is enabled.
(From OE-Core rev: 2f539a1318a80d3ad5d0d43a9ba4070465e402af)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When used with `--newbuilddir` option, it replaces relative paths in
BBLAYERS variable with absolute paths by evaluating the final value of
the variable, converting paths and saving result by assignment
(`BBLAYERS =`) at the end of bblayers.conf.
This breaks tests when bblayers.conf contains BBLAYERS:append because
:append statements are evaluated after all assignments and we end up
with the appended layer added twice - first by evaluating final value
of the variable, then again by bitbake evaluating BBLAYERS:append.
The error is as follows:
AssertionError: Command 'bitbake -e' returned non-zero exit status 1:
ERROR: Found duplicated BBFILE_COLLECTIONS 'layer-name', check bblayers.conf or layer.conf to fix it.
(From OE-Core rev: 516c8e8f722ed0eb85a715a23b5e68d05abe9275)
Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SPDX code needs to be able to look up an Element by its SPDX ID,
locating the file that (should) contain the SPDX ID and opening it for
parsing. Previously, the code would do this be hashing each Element
SPDX ID and Alias, and the creating a symbolic link to the file that
contains the element with a name of the hash.
This worked well as it was possible to look up any arbitrary SPDX ID or
alias by simply hashing it and following the symbolic link to get the
file. However, the down side of this approach is that it creates a lot
of symbolic links, since it will make one or two per Element in the
document. This can be a problem when using SPDX_INCLUDE_SOURCES, for
example.
This change reworks this strategy so that the only Element that gets a
symbolic link based on the hash is the singular SpdxDocument that is
create for each file. All other Elements are assigned an alias with a
special prefix that encodes the hash of SpdxDocument alias. Thus, when
attempting to look up an arbitrary alias, the code sees the special
prefix, extract the hash, opens the file based on the symlink with that
hash name, then finds the matching Element in the file. This drastically
reduces the number of symbolic links by making only one per file.
This also means that the custom link extension can be removed since it
is now superfluous.
(From OE-Core rev: 838d64c09657ac53175737fc4e7fd6f01f3dcf47)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The check to see if a provider of a given package is listed first
checks for an exact match of the provider name. However, if this match
existed, but didn't match in the task dependencies, it would not
continue to look for other providers of package. This would manifest if
one (non-virtual) recipe package RPROVIDES the name of a package
produced by another recipe.
Fix this, and also clean up the code to make it more readable by using a
function to check if a runtime dependency is in the task dependencies.
In addition, if no provider is found, list all the possible providers
instead of the last one that was looked at.
(From OE-Core rev: f13de6ab616eb1e38960a2296111febe2a9f4a28)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
