linux/poky.git/scripts, branch genericarm64

devtool: ide: vscode: Configure read-only files

2024-02-20T12:58:41+00:00

When debugging or browsing files, the user may fall into external sources from other packages in the sysroot or dbg-rootfs. Modifying them will only lead to confusion since they will be overwritten by Yocto. The user should open them in a separate devtool modify session if they want to make changes. Meanwhile, we should prevent write access to them. (From OE-Core rev: 8a95ad9aecb81732c865e00a987bb8bd3d6cb91d) Signed-off-by: Enguerrand de Ribaucourt Signed-off-by: Richard Purdie

devtool: ide_sdk: Use bitbake's python3 for generated scripts

2024-02-20T12:58:41+00:00

The generated scripts use the sys.path configuration found inside bitbake. It can be a different python version than the one used on the host through the IDE. For instance, when running the generated script deploy_target_cmake-example-core2-64 from an eSDK generated on another machine, I got the following exception: AssertionError: SRE module mismatch We need to match the sys.executable to the sys.path. (From OE-Core rev: 45704319661570b45ef69fddd6b4b4fa22ca80d1) Signed-off-by: Enguerrand de Ribaucourt Signed-off-by: Richard Purdie

recipetool; add support for python_mesonpy class

2024-02-20T11:39:45+00:00

* 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. (From OE-Core rev: 256749322671d2f4ea994db671d73c4de10e1723) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

lib/oe/patch: Use git notes to store the filenames for the patches

2024-02-19T16:03:22+00:00

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: ", 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 Signed-off-by: Richard Purdie

devtool: Make use of oe.patch.GitApplyTree.commitIgnored()

2024-02-19T16:03:22+00:00

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 Signed-off-by: Richard Purdie

oe-setup-build: add a tool for discovering config templates and setting up builds

2024-02-19T11:47:53+00:00

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 Signed-off-by: Richard Purdie

scripts/oe-setup-builddir: add support for configuration summaries

2024-02-19T11:47:53+00:00

They are handled exactly same as conf-notes.txt. (From OE-Core rev: 6fd2eb619693da4cb918b421f3e31072b48fa85a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

patchtest: add stronger indication for failed tests

2024-02-19T11:39:08+00:00

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ß Signed-off-by: Richard Purdie

scripts/oe-setup-layers: write a list of layer paths into the checkout's top dir

2024-02-19T11:39:08+00:00

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 Signed-off-by: Richard Purdie

oe-init-build-env: generate .vscode from template

2024-02-19T11:34:33+00:00

Provide a reasonable default configuration for VSCode and the yocto.bitbake extension. The generated default configuration is generic and minimal. It's mostly supposed to prevent VSCode from OOM exceptions if the build directory is in the scope of the indexer plugins of VSCode. But it also configures the yocto-bitbake plugin to just work without manual user interaction. The configuration is only generated if VSCode is installed. Currently, VSCode is one of many popular editors for Yocto/OE. Removing the check would mean that the configuration would be generated by e.g. oe-selftest or for users not using VSCode. If it should prove useful, the check can be removed later. Customization for other layers is possible. A layer might provide it's own oe-setup-build-env script which calls the oe-setup-vscode script from poky with different folders. But it's also possible to override the oe-setup-vscode script by another layer with a custom implementation. (From OE-Core rev: 48829be7ab2edcbc2e4473f81cdaf35889d63f9c) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie