In nanbield these are no longer needed - spaces are sufficient.
The code still handles any semicolons (replacing them with spaces before
interpreting the value), but let's avoid people adding them from now on
in case we decide to change that in future.
(From yocto-docs rev: 2947f6309f86cdf5322a39d4420e77431a8e3572)
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update for changes in nanbield. Note that I am documenting what is set
by poky.conf here (since this is Yocto Project documentation), which is
slightly different from what is done in meta/conf/bitbake.conf.
(From yocto-docs rev: 9764cb9e19788eb1caea0d2e95fbe7a5c19887d4)
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a Map to detail how BitBake handles a recipe's tasks
and its compile/runtime dependencies along with detailed comments.
(From yocto-docs rev: 7f0ab56aa302babab6c9d600a8d8a91708cf75f7)
Signed-off-by: Talel BELHAJSALEM <bhstalel@gmail.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extend the description on how to prepare a patch for a CVE issue.
Add a more illustrative and current example of how to modify
the patch file. Add an example of how to use CVE_STATUS.
(From yocto-docs rev: f982f6be6b52ba0915b2e6f712270dec5dde64fc)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
No longer in use in Poky (dropped in Nanbield through
multiple commits)
(From yocto-docs rev: e5d39e85a0db27bfc857fae9649f799179888eee)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Mention CVE_STATUS_GROUPS in the development manual
(otherwise only present in the reference manual, but with
no reference to it)
- In the reference manual description of CVE_STATUS,
link back to the development manual, to provide context.
(From yocto-docs rev: cfef5fe41b6c819e783c88829448ae38141650a5)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove a reference to a web resource which is clearly marked as obsolete.
Replace the unnecessarily verbose note by just links to the mentioned tools.
[YOCTO #15233]
(From yocto-docs rev: 3f979f5d2446d57d75f0c4ad2199510d533880e8)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Make it clear that patchtest only supports openembedded-core for now
- Add a short list of instructions for installing Python module
dependencies on the host
- Add a step to add meta-selftest with bitbake layers so that all tests
can run
(From yocto-docs rev: bcd58d68e72226be1930593f5f7fb37de15b7913)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As discussed before with Richard Purdie, the code supports this but the documentation does not.
Developers in general will not notice this or focus on it because they do not mess with the
layer.conf template file, but in my opinion I think more details can help.
(From yocto-docs rev: 15fc103d4ddd14698c8e75cc654ac157ca1ad740)
Signed-off-by: Talel BELHAJSALEM <bhstalel@gmail.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
COMPATIBLE_MACHINE is used to forbid the use of a recipe or its packages
for a specific set of machines.
In some cases, it may make more sense to have the logic inverted and
have the recipe always forbidden except for hand-picked machines. Such
could be the case for pieces of software that only support some
architectures. In that scenario, it is sometimes a bit easier on the eye
and for maintenance to use the OVERRIDES mechanism but for that, a
default should be set.
COMPATIBLE_MACHINE:aarch64 = "^(aarch64)$"
COMPATIBLE_MACHINE:mips64 = "^(mips64)$"
wouldn't do much because if COMPATIBLE_MACHINE isn't set, the recipe is
assumed compatible and therefore, if no default is provided we enter
that case.
Hence, we need to add
COMPATIBLE_MACHINE = "^$"
as default so that it only matches the empty string, which isn't
possible for MACHINEOVERRIDES.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From yocto-docs rev: 52196d39bc85de267daffb0074eb59786751f57d)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various aesthetic cleanups of section 1 of that manual, including:
* replace 'HOWTO' with manual
* add more examples of sdk-related images
* font fixes
(From yocto-docs rev: 608e93e13a8316a8d40e0675d4335084efa3736a)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGECONFIG's first and second flag value will be added to PACKAGECONFIG_CONFARGS
and then it will be added to the appropriate variable (EXTRA_OECMAKE, or ...)
So we need to only mention PACKAGECONFIG_CONFARGS and it will lead to other variables.
I added a custom example that can help understanding very well PACKAGECONFIG.
(From yocto-docs rev: 7f26b0c0a08d6be9810128369265b0c494e7191b)
Signed-off-by: Talel BELHAJSALEM <bhstalel@gmail.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
