For use in the documentation.
(Bitbake rev: ed90b2ef95564b79d28a20e0e217e13be110499b)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- improve bb-layers property description
- add bb-layers-file-relative property
The rationale is that both properties are relative to their respective directories
and that should be documented and clear from their names (without being too verbose).
Based on a patch from Alexander Kanavin <alex@linutronix.de> but with
updated naming.
(From OE-Core rev: b9d761c06350020e14e09c5bfa7b92eded43d889)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The difference between bb-layers and bb-layers-relative is unclear as both
are relative paths. Rename one to "file-relative" which makes it clear it
is relative to the current file, without becomming a long name.
https://lists.openembedded.org/g/bitbake-devel/message/18296
Based on a patch from Alexander Kanavin <alex@linutronix.de> but
with different naming.
(Bitbake rev: dcb17758b99767ab6da4172cf60eabc9269082dd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
{THISDIR} is a special value token that can be used in the list of enabled
layers to specify the layer location relative to the confguration file:
https://git.openembedded.org/bitbake/commit/?id=b3153be29de8b8570b0c184369bd41f4c646cf92
This replaces the token with an explicit separate keyword for such layers:
so that special processing to determine the final value can be avoided, and
the feature can be formalized in the json schema:
instead of
"bb-layers": [
"{THISDIR}/meta-my-project"
]
this allows
"bb-layers-relative": [
"meta-my-project"
Going forward I think we should strive to avoid any further special value tokens.
(Bitbake rev: 90da82bd2bfcfd5590c9ae06015737b616074b56)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When initializing a build setup from a conf.json that only sets 'rev'
to a tag or branch, the actual revision would not be captured or
logged.
To capture the current layer state after an 'init' or 'update', the
checkout_layers function is extended to store the revision the
bb.fetch.Fetch pulled, and write that information into a
sources-fixed-revisions.json file. This file can then be fed back into
bitbake-setup init as: --sources-overrides
This new 'sources-fixed-revisions.json' is written during 'update_build' and
stored alongside the 'config-upstream.json' in the config dir. And put
with the later under version control by calling 'commit_config" after
'update_build'.
The use of 'deepcopy' is necessary to not modify the original input
data - which python passes around as reference.
(Bitbake rev: 95866ff03f78e987ae7e47daad053bc0f353eea4)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All places that called into 'check_setupdir_files' did the same
preparation step to load the upstream-config.json and then pass it
into the function.
Since the 'setuppath' is already passed into the function, and the
name and relative location of the upstream-config.json is fixed,
constructing the file path and loading the json could be done in the
function.
De-duplicate code by loading the json inside the function instead.
(Bitbake rev: 16d77c83ae3ce92ddab84d714a93fd3bb7def5e2)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Construct the 'src_uri' separately, and then pass either variant into
one call that creates the Fetch. Making use of format-strings to
shorten/simplify the code.
Also: using 'proto' instead of 'type' for a variable name, to avoid
the protected keyword.
(Bitbake rev: 4ad70e05ceca19c1e903dafc33386a82b1176bba)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename the function to reflect which (of the possibly many) files in
the build/config directory it writes to.
(Bitbake rev: 7f9cd4c1e91d110085d74f9b9f12884f97f4e8dd)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting a key=value in a new section would raise a key-error when
using in-memory settings, e.g:
./bin/bitbake-setup --setting default top-dir-prefix /tmp/bitbake-setup --setting default top-dir-name gs settings foo bar baz
Loading settings from
/tmp/bitbake-setup/gs/settings.conf
Traceback (most recent call last):
File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 853, in <module>
main()
File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 838, in main
all_settings = merge_settings(builtin_settings, global_settings, topdir_settings, args.setting)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 733, in merge_settings
all_settings[section][setting] = value
~~~~~~~~~~~~^^^^^^^^^
KeyError: 'foo'
(Bitbake rev: 78ab0d15dff5ccf64b0bf681185370779e6cabaf)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename the function to align with the corresponding
'global_settings_path' function, and move it down just above the
later.
This is done to differentiate from the built-in default settings, and
to align with the other places in the code that use 'topdir_settings'
(or 'global_settings')
(Bitbake rev: 3df994f773abbd1d0240e721f5fd29d4b021bfb5)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace HOMEPAGE, because wiki.gnome.org ‘has been retiredʼ (said on the
site).
(From OE-Core rev: b501eeaafde639b6da4f9bfeaeb76b40c7e92633)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Dropping CVE_PRODUCT, because it was equal to the default.
(From OE-Core rev: 2b7e57466940a2b3a303fca1de67fb3524cf2c78)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO 14649]
The default 3s test execution timeout isn't always enough for the check_cwm test
on the autobuilder in case there is a high load on the host machine,
and due to this this case fails sometimes.
This patch doubles the timeout for this testcase to 6 seconds to allow enough
time for execution even if there is high CPU usage by other processes.
(From OE-Core rev: 561aba8d38d1e15d23bd13736013825bd04aff2c)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch from upstream to resolve CVE-2025-11232:
Invalid characters cause assert
To trigger the issue, three configuration parameters must have
specific settings: "hostname-char-set" must be left at the default
setting, which is "[^A-Za-z0-9.-]"; "hostname-char-replacement" must
be empty (the default); and "ddns-qualifying-suffix" must NOT be empty
(the default is empty). DDNS updates do not need to be enabled for
this issue to manifest. A client that sends certain option content
would then cause kea-dhcp4 to exit unexpectedly.
(From OE-Core rev: f9331b42fd8b0df64517969a794a93d41624bd96)
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>
Omit most of the build dependencies of rpm-sequoia-native as it
needs only OpenSSL, and implicitly, libgcc and the C runtime
to run.
The list of build dependencies were determined by
$ bitbake -e rpm-sequoia-native 2>&1 | grep ^DEPENDS=
DEPENDS="pkgconfig-native cargo-native openssl-native python3-native rust-native rust-native"
Omitting these (except openssl-native) can save significant
amount of disk space and it also speeds up packaging into
signed rpms a little.
Omitting rust-native (and implicitly, llvm-native) also avoids
conflicts with different LLVM/CLANG versions, like those found
in meta-clang-revival.
(From OE-Core rev: 805227759dbd8303124f25c46f928848cf045cc6)
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>From https://lists.x.org/archives/xorg-announce/2025-October/003635.html:
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2chttps://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
(From OE-Core rev: f3b5fc0174478e1ab6d3d03c8fdc75be28d0fd3b)
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>
>From https://lists.x.org/archives/xorg-announce/2025-October/003635.html:
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2chttps://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
(From OE-Core rev: 50b9c34ba932761fab9035a54e58466d72b097bf)
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>
The underlying issue with -fno-common was resolved upstream in xserver
21.1.0 onwards[1].
[1] xserver 0148a15da ("compiler.h: don't define inb/outb and friends on mips")
(From OE-Core rev: 74b77ee90efd50a703af76769fac66a0f7c394ca)
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 adds support for the new bitbake-setup:
* Maintain backwards compatibility for poky-classic releases
* Assume bitbake-setup for all releases 'master' and forward
* When no ".templateconf" assume Poky and not OE
* Generate and use "init-build-env" script instead of 'oe-init-build-env'
directly, but "cd" to the clone and not the local installation.
* Include "bblayers.conf" because "cookerdata.py" now explicitly
required it, and let it be over-ridden by the usual "toaster-bblayers.conf".
* Force the value "TOPDIR" in "toaster.conf" to the local project's directory.
Normally "cookerdata.py" sets TOPDIR from getcwd(), but somehow in bitbake-setup
mode the CWD at this point has become ".../layers/openembedded-core", so
"bitbake.conf and all other files cannot be found. This non-obvious problem was
hard to discover. Until this is understood, the forced value will make things work.
[YOCTO #16012]
(Bitbake rev: 22b3fd418efc10da7e4a8c1725de285714d2396b)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After a terminology review by Antonin we brainstormed
something less confusing than 'build' and 'build directory'
for the place where bitbake-setup clones layers and
creates a *bitbake* build directory in. People are bound
to get these two confused and mix them up, and 'setup' is
much more distinct and aligns nicely with 'bitbake-setup'.
It's also not claimed by anything else in OE/Yocto.
So before:
top-dir -> build-dir (can be several) -> bitbake build dir, layer dir, config dir
Now:
top-dir -> setup-dir (can be several) -> bitbake build dir, layer dir, config dir
This also updates the respective command line options, I understand it's
a breaking change, but as before the tweaks are simple and we need to get the
terminology right for the users, and now is the time to do it.
(Bitbake rev: eeb81a35bf0304451f7612950d5156ea7ff18bad)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
6.16 in branch name for 6.17 kernel does not look correct.
$ git branch -r --contains 459fdea93914f4db040bd8ebf8bce134a4cd6388
linux-yocto/v6.17/standard/genericarm64
(From meta-yocto rev: 66ea31cee15309af07afeee8dec8a6fe1d92d28e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding a 6.17 kernel bbappend so the hardware reference BSPs
can be tested against the newer kernel (but it is not the
default)
(From meta-yocto rev: 4d15f394f8862cca77eb780e7bfcd945f9aae5f4)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had previously dropped the genericarm64 as it was using
standard/base for builds. But we have some temporary serial
patches only for these platforms, so we we are building out
of standard/genericarm64 to isolate those patches.
As a result, we do need to set our SRCREV to ensure that
the content is built on the branch.
Note: we can also move these to the main linux-yocto recipes
as genericarm64 has broad scope and is more than just an
indidual hardware reference BSP.
(From meta-yocto rev: 6257391c9594ed59f18ce1f7bf9bf7323d55a868)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extend the current documentation of PERSISTENT_DIR:
- Mention that it also contains the hash equivalence database when
BB_HASHSERVE = auto.
- Mention that it should not be shared between builds.
[YOCTO #15727]
(Bitbake rev: 682c2dccb67a57ecbf93aac8e9deea88bff10155)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding documentation for having an empty first component for the
SRCREV_FORMAT.
(Bitbake rev: 37ef26cfd5441ce97ff7ec0d5026c92091224c07)
Signed-off-by: Patrick Vogelaar <patrick.vogelaar.dev@mailbox.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current wording makes it difficult to understand what
exactly is done with INHERIT-ed anonymous functions and
when.
(Bitbake rev: f06af69458083735e69f115edf73f783f18bc08c)
Signed-off-by: Adam Blank <adam.blank.g@gmail.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix encountered style issues in the fetching section.
Mention that "subdir" and fetcher specific parameters can stack-up.
(Bitbake rev: 5cb35734c7056aa183bc15d454e125b75267449b)
Signed-off-by: Adam Blank <adam.blank.g@gmail.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Describe the roles of AUTOREV and SRCREV_FORMAT in the fetching step.
Add their missing descriptions to the variable reference section.
Fixes [YOCTO #14498]
(Bitbake rev: fbf0a8c5711f56bd64ae4c9d2c1d5ba884508c9f)
Signed-off-by: Adam Blank <adam.blank.g@gmail.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--global was defined twice (for settings command as a whole, and specifically
for set/unset sub-commands), which caused 'settings --global set ...' to
be allowed, and at the same time not have any effect. 'settings set --global'
is the only valid form after this change.
(Bitbake rev: 2f14cf68f6c653b6da90180a99a22c58855b0cef)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Tested-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The actual variable name used in oe-core is OE_FRAGMENTS_BUILTIN,
which is in a consistent format with other OE_FRAGMENTS_XXX vars.
(Bitbake rev: 86c5f6aa59980d04264bc526976a49fdf749d1af)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The regex used to detect bitbake files was improved in patch 9.1.1732.
Update the plugin to match that logic and fix a bug where the wrong
expression was used to set the file type
(Bitbake rev: 7ce0c9b44968f80a6060f9f9ff2cc00823b772cc)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Layer names and path are often redundant. Allow users to omit the path
key when it is equal to the layer name by using the layer name as a
default value for its path.
For example, from layers.example.json:
"sources": {
"meta-alex": {
"path": "meta-alex"
},
"meta-intel": {
"path": "meta-intel"
},
"poky": {
"path": "poky"
}
},
Update the schema to stop requiring "path" and remove it in example for
"meta-intel".
(From OE-Core rev: 7f36f0526fae5a81f9bc02e16cc849a2b1ea5797)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pick patches as listed in NVD CVE report.
Note that Debian lists one of the patches as introducing the
vulnerability. This is against what the original report [1] says.
Also the commit messages provide hints that the first patch fixes this
issue and second is fixing problem with the first patch.
[1] https://jvn.jp/en/jp/JVN19358384/
(From OE-Core rev: 2eed0deab456df4ef8876afe0710c9c89b41d45f)
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>
When enabled, users will see:
===
Poky (Yocto Project Reference Distro) 5.2.99+snapshot-1dac0d15f2d979128cb449b59bf5fd69b4ba5084 qemux86-64 ttyS0
Type 'root' to login with superuser privileges (no password will be asked).
qemux86-64 login:
===
(From OE-Core rev: 53631281573c7e7d8ca45dd30af990f8dd7b8e39)
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>
More or less all of testimage relies on logging in as root, without password,
both on console and over ssh. Previously this was enabled by default in poky
and core, but now that it isn't, testimage will error out on timeouts in
both console and ssh login attempts. This commit adds an earlier check and
provides a hint to the users about what they should do.
(From OE-Core rev: c0ac4a4b694a7550bda0b6c14e42f3705ca0a499)
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>
Please see this for background/some discussion:
https://lists.openembedded.org/g/openembedded-architecture/topic/115913545
Care should be taken to not enable this by default, and especially not for
production images. Poky and oe-core default templates did it, and it was
not a good starting point. Hopefully the fragment name, and the description
that users will see when enabling the fragment will provide enough warning.
(From OE-Core rev: e135458415dea5bbc4651e05dafe0b6903b65751)
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>
Such descriptions can contain useful or important information, and users may
not see that otherwise at all. To reduce clutter in CI outputs or similar
scenarios, -q option suppresses that printing.
(From OE-Core rev: 7d99882726cd2c2a2c162e0a2636fd7fdd330977)
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>
