summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2024-02-19recipetool; add support for python_mesonpy classtimo/python_mesonpyTim Orling
* Add support to detect the "mesonpy" build-backend for recipetool create. * Add oe-selftest case for creating a recipe for "siphash24" from pypi. https://pypi.org/project/siphash24/ This is by far the simplest recipe using the mesonpy build backend. Upstream does not provide LICENSE file(s) and we do not detect the LICENSE so don't check for that result in the test. Likewise, upstream does not define HOMEPAGE, so skip that result. Signed-off-by: Tim Orling <tim.orling@konsulko.com>
2024-02-19python3-numpy: inherit python_mesonpyTim Orling
Replace the deprecated setuptools3 bbclass with python_mesonpy. The build-backend has been defined as "mesonpy" since: https://github.com/numpy/numpy/commit/942fb8caf33a65e449fbf198ecf1cd39be953248 The vendored meson-python was dropped in: https://github.com/numpy/numpy/commit/6544e33ac7a3a600c2fb565401c811a17ecdb3d5 While we are at it: * Drop ${PYTHON_PN} and use python3 instead * Sort RDEPENDS alphabetically The ptests run, but we still have issues with sufficient memory and free disk space (the reason python3-numpy is in PTEST_PROBLEMS). Signed-off-by: Tim Orling <tim.orling@konsulko.com>
2024-02-19python_mesonpy.bbclass: move from meta-pythonTim Orling
Move the PEP-517 back-end bbclass from meta-python to support: [build-system] build-backend = "mesonpy" This is the declared backend in python3-numpy since: https://github.com/numpy/numpy/commit/942fb8caf33a65e449fbf198ecf1cd39be953248 Signed-off-by: Tim Orling <tim.orling@konsulko.com>
2024-02-19python3-meson-python: move from meta-pythonTim Orling
meson-python is a Python build backend built on top of the Meson build-system. It enables you to use Meson for your Python packages. https://meson-python.readthedocs.io/en/latest/ It is used as the PEP-517 build-backend for python3-numpy and python3-scipy. For other projects using the backend, see: https://meson-python.readthedocs.io/en/latest/projects-using-meson-python.html Signed-off-by: Tim Orling <tim.orling@konsulko.com>
2024-02-19lib/oe/patch: Use git notes to store the filenames for the patchesPeter Kjellerstedt
The old way of keeping track of the filenames for the patches that correspond to the commits was to add a special comment line to the end of the commit message, e.g., "%% original patch: <filename>", using a temporary git hook. This method had some drawbacks, e.g.: * It caused problems if one wanted to push the commits upstream as the comment line had to be manually removed. * The comment line would end up in patches if someone used git format-path rather than devtool finish to generate the patches. * The comment line could interfere with global Git hooks used to validate the format of the Git commit message. * When regenerating patches with `devtool finish --force-patch-refresh`, the process typically resulted in adding empty lines to the end of the commit messages in the updated patches. A better way of keeping track of the patch filenames is to use Git notes. This way the commit messages remain unaffected, but the information is still shown when, e.g., doing `git log`. A special Git notes space, refs/notes/devtool, is used to not intefere with the default Git notes. It is configured to be shown in, e.g., `git log` and to survive rewrites (i.e., `git commit --amend` and `git rebase`). Since there is no longer any need for a temporary Git hook, the code that manipulated the .git/hooks directory has also been removed. To avoid potential problems due to global Git hooks, --no-verify was added to the `git commit` command. To not cause troubles for those who have done `devtool modify` for a recipe with the old solution and then do `devtool finish` with the new solution, the code will fall back to look for the old strings in the commit message if no Git note can be found. While not technically motivated like above, the way to keep track of ignored commits is also changed to use Git notes to avoid having different methods to store similar information. (From OE-Core rev: f5e6183b9557477bef74024a587de0bfcc2b7c0d) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19patch.bbclass: Make use of oe.patch.GitApplyTree.commitIgnored()Peter Kjellerstedt
This makes use of the oe.patch.GitApplyTree.commitIgnored() function to create commits that shall be ignored by `devtool finish`. (From OE-Core rev: 2393dc35a93546eccee0dd313a6927c7d1512c3b) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19devtool: Make use of oe.patch.GitApplyTree.commitIgnored()Peter Kjellerstedt
This makes use of the oe.patch.GitApplyTree.commitIgnored() function to create commits that shall be ignored by `devtool finish`. (From OE-Core rev: 4e1b9289450b5e7946bd5999c95a3ee214aab8a5) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19lib/oe/patch: Add GitApplyTree.commitIgnored()Peter Kjellerstedt
This function can be used to create a commit that devtool will ignore when creating/updating the patches. (From OE-Core rev: 94f0838b9223b7ece7affaa707e54a5d784da25e) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19lib/oe/patch: Make extractPatches() not extract ignored commitsPeter Kjellerstedt
If a commit is marked with "%% ignore" it means it is used by devtool to keep track of changes to the source code that are not the result of running do_patch(). These changes need to actually be ignored when extracting the patches as they typically make no sense as actual patches in a recipe. This also adds a new test for oe-selftest that verifies that there are no patches generated from ignored commits. (From OE-Core rev: c3d43de7e54189bf09fbe8e87ddb976e42ebf531) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19swig: upgrade 4.1.1 -> 4.2.0Anuj Mittal
(From OE-Core rev: 93cf900c697685d0749c3269806213f89fb6526e) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19overlayfs-etc: add option to skip creation of mount dirsbaruch@tkos.co.il
The 'preinit' script can't create mount directories when rootfs is read-only. Add an option to skip this step. The user must make sure that all required directories are already in the rootfs directory layout. Cc: Vyacheslav Yurkov <uvv.mail@gmail.com> (From OE-Core rev: 3d433d8559467d255bd19af2d0999c65ea24a48d) Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch2/git: Make latest_versionstring extract tags with slashes ↵Peter Kjellerstedt
correctly Before, everything up to the last slash was removed when extracting the names of the tags. This would lead to that a tag such as "agent/11.0.0" would be incorrectly identified as "11.0.0", which would then be treated as a correct version matching "^(?P<pver>\d+(\.\d+)+)". (Bitbake rev: 8b21024b9966d5158ac4a77e87ffb935c2a57764) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch2/git: A bit of clean-up of latest_versionstring()Peter Kjellerstedt
This is mostly preparations for the next commit. (Bitbake rev: dcd2abfde55cc59d9869a7c97620b6fc30a52047) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: tests/fetch: Make test_git_latest_versionstring support a max versionPeter Kjellerstedt
In some cases, the version found by latest_versionstring() may be higher than the real version. Make it possible to specify a maximum version so that this case can be detected. (Bitbake rev: 9134d4777109bc78410c3e641420d9a78b485e33) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch2/git.py: add comment in try_premirrorsChen Qi
The purpose of ensuring 'incremental fetch' is not easy to see from the codes. So add comments to explain this. (Bitbake rev: 8b890b87e30cd05ec92ed71ee3691a47b4d77253) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: tests/fetch.py: add test case for using premirror in restricted networkChen Qi
We had issue when BB_ALLOWED_NETWORKS is set and `bitbake grpc-native -c fetch' failed even with all contents available in PREMIRRORS. Add a test case to ensure no regression in the future. (Bitbake rev: 80c91ceb81b1cae203067af58d3f1fe9c619ae83) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch2/git.py: fix a corner case in try_premirrorChen Qi
For gitsm recipes, it's possible that some URL is used more than once. e.g., A -> B:rev1 (B is a submodule of A) A -> C (C is a submodule of A) C -> B:rev2 (B is a submodule of C) A anc C are both using B as submodules, but on different revs. Now if we have: B:rev1 -> D B:rev2 -> E Then, the mirror will not be fully used. Say we have all repo mirrors for A, B, C, D, E, then in theory it's not necessary to reach out to any network for downloading. But it's not the case. After downloading B(rev1) and its submodule D from mirrors, the fetch process continues to download C, thus B(rev2) and E. Now it finds that B needs an update because its submodule E needs an update. Of course this is true because E is not downloaded yet. Now the problem comes to whether to use mirror or not. The git.py defines try_premirror to return 'False' when the ud.clonedir exists. As B has been cloned, the ud.clonedir exists and try_mirror returns False, resulting in not using mirror and going to upstream directly. We can see that the mirrors are not fully used. This is usually not problem, as the cost is only some network download. But in case the following two settings are there, we get errors. BB_NO_NETWORK = "0" BB_ALLOWED_NETWORKS = "*.some.allowed.domain" In such case, the gitsm recipe A will fail to fetch. Note that all contents that A needs are in mirrors and now it's failing to fetch. This is unexpected. Note that the different revs of the same repo in gitsm recipe is not the only way to reveal this problem. For example, there might be a recipe call B that uses B:rev3. Check the protobuf and grpc recipes as an example. For now, we can use the following steps to reproduce this issue. To be clear, the grpc recipe in meta-oe is now 1.60.0. 1. Add in local.conf: DL_DIR = "${TOPDIR}/downloads-premirror" bitbake grpc -c fetch 2. Comment out the DL_DIR setting in local.conf and add the following lines: PREMIRRORS:append = " \ git://.*/.* git://${TOPDIR}/downloads-premirror/git2/MIRRORNAME;protocol=file \n \ gitsm://.*/.* gitsm://${TOPDIR}/downloads-premirror/git2/MIRRORNAME;protocol=file \n \ " 3. Set BB_NO_NETWORK = "1" and then 'bitbake grpc -c fetch'. This command succeeds and this shows that the premirror holds everything we need. 4. Add the following lines and then 'bitbake grpc -c fetch'. BB_NO_NETWORK = "0" BB_ALLOWED_NETWORKS = "*.some.domain" After step 4, the error message is as below: ERROR: grpc-1.60.0-r0 do_fetch: The URL: 'gitsm://github.com/protocolbuffers/protobuf.git;protocol=https;name=third_party/protobuf;subpath=third_party/protobuf;nobranch=1;lfs=True;bareclone=1;nobranch=1' is not trusted and cannot be used This patch fixes this problem by handling this corner case, that is, if the URL is not trusted from the settings of BB_NO_NETWORK and BB_ALLOWED_NETWORKS, then we should try premirrors because trying to reach upstream is destined to fail. (Bitbake rev: e1be272ad105b47d3131b77168d9172386993fcb) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19ell: update 0.61 -> 0.62Markus Volk
ver 0.62: Add support for cleanup functions and macros. Add support for setting DHCP max attempts. (From OE-Core rev: ae84d13b6c4f33a56cc36715a118a9f938ceb2c4) Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19initramfs-framework: overlayroot: align bootparams with module nameJohannes Schneider
Renaming the 'rootrw' kernel commandline parameter to 'overlayrootrwdev' to both align better with this modules name, and point out the usage of the variable. This patch also includes an if block to migrate the old 'rootrw' block, should it be already used by someone. (From OE-Core rev: a52b7f5c8ff3e50707b55843d9996983ab8efae2) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19initramfs-framework: overlayroot: fix kernel commandline clashJohannes Schneider
The initramfs-framwork takes kernel commandline options and converts them for internal use to variables following the 'bootparam_name' pattern. The overlayroot module uses 'bootparam_rootfstype' and 'bootparam_rootfsflags' which both collide with linux kernel parameters 'rootfstype' and 'rootfsflags'. This collision is solved by putting the variables in the namespace of the initramfs-framework module. (From OE-Core rev: ef20ef719c699b94fc52b81c520faa0b3714efeb) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: tests/fetch.py: add multiple fetches testPavel Zhukov
Fetch from premirror few times to emulate multiple machines sharing same clonedir or few rebuilds of the package from (pre)mirror Regression test for [Yocto #15369] (Bitbake rev: 7fcbac574c68f16b95ab7abb2874931d168d3c9e) Signed-off-by: Pavel Zhukov <pavel@zhukoff.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch2/git.py: Fetch mirror into HEADPavel Zhukov
Fix the issue with using of (pre)mirror in case if clonedir exists but outdated. Previous version of the code fetched new mirror content into FETCH_HEAD instead of branch which caused refetch from the upstream. Add new remote add fetch from it instead so the ref can be found by "_contains_ref" Fixes [Yocto #15369] (Bitbake rev: 69588e2a5c7c200e47b02b2391498dcb72388bd2) Signed-off-by: Pavel Zhukov <pavel@zhukoff.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: git-make-shallow: support git's safe.bareRepositoryAndré Draszik
When git is configured with safe.bareRepository=explicit [1], the git-make-shallow fails miserably. LWN has an article about the problem that this configuration option addresses and why it is useful in [2]. It also seems that it is being rolled out in some environments as a default for users. In order to allow having this configuration turned on for a user's environment in general, the fetcher has to be tought to use --git-dir= for all relevent git operations. The alternative, implemented here, is to forcibly turn off that option for all git operations. In the future, we could look into converting these to using the --git-dir= command line argument instead. Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1] Link: https://lwn.net/Articles/892755/ [2] (Bitbake rev: 7c63989db4590564516ed150930f4e2fa503e98f) Signed-off-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: tests/fetch: support git's safe.bareRepositoryAndré Draszik
When git is configured with safe.bareRepository=explicit [1], the bitbake selftests fail miserably. LWN has an article about the problem that this configuration option addresses and why it is useful in [2]. It also seems that it is being rolled out in some environments as a default for users. In order to allow having this configuration turned on for a user's environment in general, the fetcher has to be tought to use --git-dir= for all relevent git operations. The alternative, implemented here, is to forcibly turn off that option for all git operations. In the future, we could look into converting these to using the --git-dir= command line argument instead. Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1] Link: https://lwn.net/Articles/892755/ [2] (Bitbake rev: a45e14a7343e36101e45639931322e5649587f57) Signed-off-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: fetch/git2: support git's safe.bareRepositoryAndré Draszik
When git is configured with safe.bareRepository=explicit [1], the bitbake git fetcher fails miserably. LWN has an article about the problem that this configuration option addresses and why it is useful in [2]. It also seems that it is being rolled out in some environments as a default for users. In order to allow having this configuration turned on for a user's environment in general, the fetcher has to be tought to use --git-dir= for all relevent git operations. The alternative, implemented here, is to forcibly turn off that option for all git operations. In the future, we could look into converting these to using the --git-dir= command line argument instead. While at it, fix one open-coded invocation of git that wasn't using ud.basecmd Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1] Link: https://lwn.net/Articles/892755/ [2] (Bitbake rev: 5f3b1d8dc9ee70e707536bd75ee845b547440c97) Signed-off-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19sanity.conf: Require bitbake 2.7.3Richard Purdie
Due to hashserv API changes in siggen, we need bitbake 2.7.3. (From OE-Core rev: 7172fd527fde440f26dd6cc371cde2720dbaa366) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19sstatesig: Implement new siggen APIJoshua Watt
Implements the new API required for querying unihashes in parallel (From OE-Core rev: 0c66d07238d20dc1b34355e4c472aa7457d2e5fe) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: bitbake: Bump version to 2.7.3 for hashserv changesRichard Purdie
(Bitbake rev: c1e0a0b6ddc9667c9d62319bd9ccd4eb8c64c2a6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: bitbake: hashserv: Postgres adaptations for ignoring duplicate insertsTobias Hagelborn
Hash Equivalence server performs unconditional insert also of duplicate hash entries. This causes excessive error log entries in Postgres. Rather ignore the duplicate inserts. The alternate behavior should be isolated to the postgres engine type. (Bitbake rev: e8d2d178d0fe96f9d6031c97328e8be17d752716) Signed-off-by: Tobias Hagelborn <tobiasha@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: siggen: Add parallel unihash exist APIJoshua Watt
Adds API to query if unihashes are known to the server in parallel (Bitbake rev: 7e2479109b40ce82507f73b4f935903f7f79fb06) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: siggen: Add parallel query APIJoshua Watt
Implements a new API called get_unihashes() that allows for querying multiple unihashes in parallel. The API is also reworked to make it easier for derived classes to interface with the new API in a consistent manner. Instead of overriding get_unihash() to add custom handling for local hash calculating (e.g. caches) derived classes should now override get_cached_unihash(), and return the local unihash or None if there isn't one. (Bitbake rev: 6faf48c09a4003a31b32e450779fb8ac9cc5e946) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: hashserv: Add Client PoolJoshua Watt
Implements a Client Pool derived from the AsyncRPC client pool that allows querying for multiple equivalent hashes in parallel (Bitbake rev: ba4c764d8061c7b88cd4985ca493d6ea6e317106) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: asyncrpc: Add Client Pool objectJoshua Watt
Adds an abstract base class that can be used to implement a pool of client connections. The class implements a thread that runs an async event loop, and allows derived classes to schedule work on the loop and wait for the work to be finished. (Bitbake rev: f113456417f9ac0a4b44b291a6e22ea8219c3a5f) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: hashserv: Add unihash-exists APIJoshua Watt
Adds API to check if the server is aware of the existence of a given unihash. This can be used as an optimization for sstate where a client can query the hash equivalence server to check if a unihash exists before querying the sstate cache. If the hash server isn't aware of the existence of a unihash, then there is very likely not a matching sstate object, so this should be able to significantly cut down on the number of negative hits on the sstate cache. (Bitbake rev: cfe0ac071cfb998e4a1dd263f8860b140843361a) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: hashserv: sqlalchemy: Use _execute() helperJoshua Watt
Use the _execute() helper to execute queries. This helper does the logging of the statement that was being done manually everywhere. (Bitbake rev: 0409a00d62f45afb1b172acbcea17bf17942e846) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: hashserv: Add Unihash Garbage CollectionJoshua Watt
Adds support for removing unused unihashes from the database. This is done using a "mark and sweep" style of garbage collection where a collection is started by marking which unihashes should be kept in the database, then performing a sweep to remove any unmarked hashes. (Bitbake rev: 433d4a075a1acfbd2a2913061739353a84bb01ed) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake: hashserv: improve the loglevel error message to be more helpfulPaul Gortmaker
Coming from a kernel background, I was thinking along the lines of dmesg -n <integer> for loglevel adjustments. So I tried various large and small and even zero number values with no luck before getting frustrated and opening up the python. Let us save others the frustration and give a hint what the args it expects should look like. (Bitbake rev: df184b2a4e80fca847cfe90644110b74a1af613e) Signed-off-by: Paul Gortmaker <paulg@kernel.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19meta-poky/conf/templates/default/conf-summary.txt: add a template summaryAlexander Kanavin
Existing conf-notes.txt is not adequate in situations where the user needs to select a config template from several, or get an overview of them and is interested only in a brief explanation of what the template is for, but not extended multi-paragraph instructions for how to use it. Such summaries can be provided via conf-summary.txt and this patch adds such a summary for the poky default template. Updates to the tools and a tool for selecting templates which will make specific use of the summary will follow. (From meta-yocto rev: 5f404da45021caa09c796dee015ff735d36fa4c0) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake-layers: Add test case layers setup for custom referencesJermain Horsman
This includes a simple test which creates a layer setup using custom references, and subsequently modifies the resulting layers setup using a different custom reference. (From OE-Core rev: 36701e78cf239261ad21cf58db2934c3c8a5e3e6) Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19bitbake-layers: Add ability to update the reference of repositoriesJermain Horsman
This creates a new layers setup with, or, modifies an existing layers setup using, one or more repositories where the references are provided by the user. This is a very minimal implementation, no validation of any reference is done and it is left to the user to provide a valid value. (From OE-Core rev: e69444de713e1ec7959c71f9cdf965d3b5a1c6be) Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19oe-setup-build: add a tool for discovering config templates and setting up ↵Alexander Kanavin
builds This is another piece of the puzzle in setting up builds from nothing without having to write custom scripts or use external tools. After layers have been fetched and placed into their respective locations by oe-setup-layers, one would surely want to proceed to the actual build, and here's how: 1. Without arguments the tool reads available layers from .oe-layers.json file (written out by oe-setup-layers or a fallback under scripts/), prints what templates it has found, and asks the user to select one, as seen below. This will land the user in a shell ready to run bitbake: ============================================= alex@Zen2:/srv/work/alex$ ./setup-build Available build configurations: 1. alex-configuration-gadget This configuration will set up a build for the purposes of supporting gadget. 2. alex-configuration-gizmo This configuration allows building a gizmo. 3. poky-default This is the default build configuration for the Poky reference distribution. Re-run with 'list -v' to see additional information. Please choose a configuration by its number: 1 Running: TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/configuration-gadget . /srv/work/alex/poky/oe-init-build-env /srv/work/alex/build-alex-configuration-gadget && /bin/bash You had no conf/local.conf file. This configuration file has therefore been created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/local.conf.sample You may wish to edit it to, for example, select a different MACHINE (target hardware). You had no conf/bblayers.conf file. This configuration file has therefore been created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/bblayers.conf.sample To add additional metadata layers into your configuration please add entries to conf/bblayers.conf. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: https://docs.yoctoproject.org For more information about OpenEmbedded see the website: https://www.openembedded.org/ This configuration will set up a build for the purposes of supporting gadget. Please refer to meta-alex/README for additional details and available bitbake targets. ============================================== 2. It is also possible to list available configurations without selecting one using 'setup-build list' or to select and setup one non-interactively with 'setup-build setup'. 3. The full set of command line options is: $ ./setup-build --help usage: setup-build [-h] [--layerlist LAYERLIST] {list,setup} ... A script that discovers available build configurations and sets up a build environment based on one of them. Run without arguments to choose one interactively. positional arguments: {list,setup} list List available configurations setup Set up a build environment and open a shell session with it, ready to run builds. optional arguments: -h, --help show this help message and exit --layerlist LAYERLIST Where to look for available layers (as written out by setup-layers script) (default is /srv/work/alex/.oe-layers.json). $ ./setup-build list --help usage: setup-build list [-h] [-v] optional arguments: -h, --help show this help message and exit -v Print detailed information and usage notes for each available build configuration. $ ./setup-build setup --help usage: setup-build setup [-h] [-c configuration_name] [-b build_path] [--no-shell] optional arguments: -h, --help show this help message and exit -c configuration_name Use a build configuration configuration_name to set up a build environment (run this script with 'list' to see what is available) -b build_path Set up a build directory in build_path (run this script with 'list -v' to see where it would be by default) --no-shell Create a build directory but do not start a shell session with the build environment from it. 4. There's an an added hint in oe-setup-layers about how to proceed (as it is really not user-friendly to fetch the layer repos successfully and then exit without a word), and a symlink to the script from the top level layer checkout directory. 5. The selftest to check layer setup has been adjusted to run a basic check for template discovery and build setup. The revision of poky to be cloned has been bumped to 4.1, as that's the first version with a default template in a standard location. (From OE-Core rev: 1360b64e88cda7dddfb0eca6a64f70c13dafb890) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19scripts/oe-setup-builddir: add support for configuration summariesAlexander Kanavin
They are handled exactly same as conf-notes.txt. (From OE-Core rev: 6fd2eb619693da4cb918b421f3e31072b48fa85a) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19meta/lib/bblayers/buildconf.py: add support for configuration summariesAlexander Kanavin
(From OE-Core rev: 7117e3d08570202c79d618d4fb6a67895b1df564) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19meta/conf/templates/default/conf-summary.txt: add a template summaryAlexander Kanavin
Existing conf-notes.txt is not adequate in situations where the user needs to select a config template from several, or get an overview of them and is interested only in a brief explanation of what the template is for, but not extended multi-paragraph instructions for how to use it. Such summaries can be provided via conf-summary.txt and this patch adds such a summary for the oe-core default template. Updates to the tools and a tool for selecting templates which will make specific use of the summary will follow. (From OE-Core rev: aa96c2064a874714cfe4bac2fa622690e4c27ee4) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19patchtest: add stronger indication for failed testsSimone Weiß
Do not only log that there has been an issue but add WARNING before for local runs. Hopefully this helps to avoid that people reading the log to quickly miss issues. Fixes [YOCTO #15389] (From OE-Core rev: 661c0a8fd8fe7bff61cea82778c25cf24d791267) Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19patchtest: Add selftest for test cve_check_ignoreSimone Weiß
Add a selftest for the recently introduced check for CVE_CHECK_IGNORE. (From OE-Core rev: dc6ebbbb94b162d8aa68e46d5a166606ace5e39c) Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19scripts/oe-setup-layers: write a list of layer paths into the checkout's top dirAlexander Kanavin
This is beneficial for setting up builds, as this list can be used to determine reliably where the actual layers are, and discover available configurations from them. Also adjust the selftest to check the presence of that file rather than any specific layer in a hardcoded location. Sample output (paths are written relative to the file for relocatability and ease of reading): { "layers": [ "meta-openembedded/meta-filesystems", "meta-openembedded/meta-gnome", "meta-openembedded/meta-initramfs", "meta-openembedded/meta-multimedia", "meta-openembedded/meta-networking", "meta-openembedded/meta-oe", "meta-openembedded/meta-perl", "meta-openembedded/meta-python", "meta-openembedded/meta-webserver", "meta-openembedded/meta-xfce", "poky/bitbake/lib/layerindexlib/tests/testdata/layer1", "poky/bitbake/lib/layerindexlib/tests/testdata/layer2", "poky/bitbake/lib/layerindexlib/tests/testdata/layer3", "poky/bitbake/lib/layerindexlib/tests/testdata/layer4", "poky/meta-poky", "poky/meta-selftest", "poky/meta-skeleton", "poky/meta-yocto-bsp", "poky/meta" ], "version": "1.0" } (From OE-Core rev: 82743f4f767f8016564be0d9d6c0d8fe9e067740) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19useradd.bbclass: Fix missing space when appending vardeps.Siong W.LIM
(From OE-Core rev: c4658401f1331026dc47a859dd665aab74918bba) Signed-off-by: Siong <wslim87@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19qemu: Set CVE_STATUS for wrong CVEsSimone Weiß
All are already fixed in 8.2.1, NVD was informed that cpes are wrong. (From OE-Core rev: a975960baffd341cd07cb093bef107c031c9b956) Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-19wayland-protocols: update 1.32 -> 1.33Markus Volk
(From OE-Core rev: 2a4cad037973a2277db60bf729ef4836c226142e) Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>