summaryrefslogtreecommitdiffstats
path: root/scripts
Commit message (Collapse)AuthorAgeFilesLines
* resulttool: Improve repo layout for oeselftest resultsRichard Purdie2024-12-091-1/+1
| | | | | | | | | | | | | | Having all oe-selftest results on top of each other results in a large 640MB json file which is hard to use. Split the results out per machine and test type. This also stops the toolchain raw logs from overwriting each other meaning more than one MACHINE is preserved. (From OE-Core rev: 92cb4641ff4ec8c1f681bca21cfeaf2ba6923ab7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 4b890f04bc7d147b4a11b824a84f3d2abd75ac54) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Trim the precision of duration informationRichard Purdie2024-12-091-0/+17
| | | | | | | | | | | The duration values have pointless amounts of precision. Removing some of the least significant digits reduces result size and makes the results easier to read. (From OE-Core rev: 7460a4bb50c696c39add79c2b299b5e636532b8c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit a789a2e6d97bb8efd663226a17db8d1ca6c1e40f) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Clean up repoducible build logsRichard Purdie2024-12-091-0/+22
| | | | | | | | | | | | We've improved the data stored for reproduicible builds. Teach resulttool how to apply those cleanups when reprocessing data so we can reduce results file sizes and make the data easier to process. (From OE-Core rev: 82acc3b1e410afd40fe8a67c77bfe69add95066e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b799c57ae6d61c1b1c7035c8a2c4ba6ee08d1a81) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Handle ltp rawlogs as well as ptestRichard Purdie2024-12-091-13/+20
| | | | | | | | | | | Improve the rawlogs handling to include ltp logs as well as the ptest ones to reduce the size of the results git repos. (From OE-Core rev: 6b164f7fe556824c85873ce2ca4257b3a4956cdf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit a0a1954d559609c2c1ca16936d0d68eb3c4c6b45) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Add --logfile-archive option to store modeRichard Purdie2024-12-091-2/+17
| | | | | | | | | | | | Storing the log files inside the testresults git repo isn't scaling and isn't really appropriate use of a git repository. Allow these to be optionally stored in a separate filesystem location so the git repo can remain managable. (From OE-Core rev: 3472833b50b5ec97ec19f510ba926ab6aa5429b3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 1afc0f3d7e93fa8496be241e9622d3b9a6904bd5) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Fix passthrough of --all files in store modeRichard Purdie2024-12-091-1/+1
| | | | | | | | | | | When using store mode, --all was broken as not all files were being preserved. Fix this by limiting the scope of the git rm command. (From OE-Core rev: 461140bede110b561f0bae46255d6a9435329e97) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 9604561d2022b6c76b1cb4186d40800d1affdd2b) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Use single space indentation in json outputRichard Purdie2024-12-093-3/+3
| | | | | | | | | | | | | Using 4 space indentation in resulted in hundreds of megabytes of extra file size in general use. Reduce this to make filesizes more managable and reduce the processing cost. Some level of indentation and spacing does make the files more readable and allows use of git diff so we need to retain some of it. (From OE-Core rev: 03fef3a99186863a0c460bd89bad40f2360a6930) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit a274cdcaf852cca9497f0358f44dda99c06aacbe) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* resulttool: Allow store to filter to specific revisionsRichard Purdie2024-12-091-0/+5
| | | | | | | | | | | | | We have a challenge on the autobuilder where test results from both OE-Core and poky are being mixed together during result storage which is confusing the data. Add a way to filter to specific revisions as the least worst way to fix the various issues this is causing. (From OE-Core rev: 974a6d5ebebc279df7c6994df7bd8c5d462e4447) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 3f276a0dc65341668788853be2cf27ab6aa12b13) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* scripts/install-buildtools: Update to 5.0.5Aleksandar Nikolic2024-12-061-2/+2
| | | | | | | | | Update to the 5.0.5 release of the 5.0 series for buildtools. (From OE-Core rev: 97841ea6f6d3d8225b4865e389815090f153ee55) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* runqemu: Fix detection of -serial parameterJörg Sommer2024-10-181-2/+2
| | | | | | | | | | | | | The pattern `-serial` matches also `-device usb-serial` and `virtio-serial` which are not the desired parameter. This causes the serial console ttyS1 is missing and Systemd's getty@ttyS1 fails constantly. (From OE-Core rev: 44c1f003d617ac20527926b4b321ffd1fe4462bb) Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b6d035894120b45b42f146ab5b3110522c58d178) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* scripts/install-buildtools: Update to 5.0.3Richard Purdie2024-10-021-2/+2
| | | | | | | | | | | Update to the 5.0.3 release of the 5.0 series for buildtools. (From OE-Core rev: 9028036392df4c49895c3c980596d26e0461febb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit c922ca720a0c3b7b4d3d3187539e7cf77d93d457) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* install-buildtools: update base-url, release and installer versionAleksandar Nikolic2024-10-021-3/+3
| | | | | | | | | | | | | | | Update the following default values: - DEFAULT_BASE_URL (https instead of http) - DEFAULT_RELEASE (5.0.1) - DEFAULT_INSTALLER_VERSION (5.0.1) (From OE-Core rev: 2c4b9af5e3f385b296e2ce0e1d8a0c43937a7334) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b2ebb965a5aa128b05ed7ddc9216171463777732) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* install-buildtools: fix "test installation" stepAleksandar Nikolic2024-10-021-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "Test installation" step fails with some harmless error messages (see [1]). This can however make a user think that the buildtools have not been installed correctly. Two reasons for the error messages: - some envvars in the environment-setup-<arch>-pokysdk-linux file start and end with double quotes (e.g., PATH) and are as such written into python os.environ. This leads that their usage is not valid later when testing the installation. This patch removes the double quotes before writing, if they are present. - if installation directory (install_dir), given through the option --directory, is given as a relative path, checking if the path to a tool (e.g., gcc) in buildtools starts it will always fail. This patch converts the install_dir variable to an absolute path. [1] ERROR: Something went wrong: tar not found in ./build-tools ERROR: Something went wrong: installation failed (From OE-Core rev: 915c48232b0e66915720bff9c745825fa169fa65) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit e4eb0b14ecf9bd2fba13260441c9d86eb348f41e) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* install-buildtools: remove md5 checksum validationAleksandar Nikolic2024-10-021-17/+10
| | | | | | | | | | | | | | | No need to validate with the md5 checksum, as the file is not even uploaded to the Yocto release webpage (the download never failed due to a wrong indentation of an else statement). For validation purposes, use the sha256 checksum only. (From OE-Core rev: 081ac6c177860c1bd7e2d4f4b873f3a760864d21) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b740d2f9d40aef1e18c022d1e82b4fb2c5c1fc22) Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* runqemu: keep generating tap devicesKonrad Weihmann2024-10-021-10/+14
| | | | | | | | | | | | | | | | | | | | in case there is no tap device the script tries to generate a new one. The new device is then unguarded for a moment, so the newly generated device could be acquired by a different instance or user, before it is locked to the instance with acquire_taplock. To fix that keep generating new tap devices in case the lock can't be acquired up to 5 times. If no tap device can be locked it fails in the existing error handling (From OE-Core rev: ae4e4fb703f63402cacbef772e70082e5760f78a) Signed-off-by: Konrad Weihmann <kweihmann@outlook.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 23876576d054ebbab9b02c0012782aa56feda123) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* wic: bootimg-efi: fix error handlingEnrico Jörns2024-08-011-2/+2
| | | | | | | | | | | | | | | | | If we check for empty variables, it does not make sense to print their content in case they are empty. Additionally, the error message in the 'kernel' check attempted to print the wrong variable ('target') which was not even defined, yet. Also, raising WicError doesn't require an extra newline. (From OE-Core rev: a1cbf4d5ea5f852144d0cc70be99d6338c618fcd) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit f31cf475d0235f42d73aeec07694f79b9937fd76) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* wic: engine.py: use raw string for escape sequenceEnrico Jörns2024-07-171-1/+1
| | | | | | | | | | | | | Fixes: | poky/scripts/lib/wic/engine.py:362: SyntaxWarning: invalid escape sequence '\/' (From OE-Core rev: ab3ed4270af1c8d4a4dd15b8c6998182801d4bce) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit e33d7241f6c2897e930aff41e18b154891197ab9) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* devtool: ide-sdk: correct help typoAntonin Godard2024-07-091-1/+1
| | | | | | | | | (From OE-Core rev: 149f79c877f476eabafc667629f89af335fcae34) Signed-off-by: Antonin Godard <antoningodard@pm.me> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 50e043387a2f0f9a5c2f7a5f914c465c830d329b) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* wic/partition.py: Set hash_seed for empty ext partitionAdithya Balakumar2024-07-031-14/+23
| | | | | | | | | | | | Although setting hash_seed is handled for the rootfs plugin case, but this is missed when deploying an empty ext partition. (From OE-Core rev: a4e7334a4b87f1bb1947f6b10f71ddb445c91d0c) Signed-off-by: Adithya Balakumar <adithya.balakumar@toshiba-tsip.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 0202fb594fb05098cb8d8b6088e63beb40b5906e) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* devtool: sync: Fix Execution errorVincent Kriek2024-06-191-1/+12
| | | | | | | | | | | | | | | | | | | | | | When executing devtool sync on a recipe that was extract with devtool extract earlier the following error occured: Traceback (most recent call last): [...] bb.process.ExecutionError: Execution of 'git fetch file:///home/vin/projects/poky/build/tmp/work/all-poky-linux/netbase/6.4/devtooltmp-figt1jmr/workdir/netbase devtool:devtool' failed with exit code 128: fatal: refusing to fetch into branch 'refs/heads/devtool' checked out at '/home/vin/projects/poky/build/netbase-src' Fix this by adding --update-head-ok and --force to git fetch so it will override the current head even if it is checked out and has changes. Possible existing changes in the devtool branch can be retrieved by checking out the devtool.bak branch (From OE-Core rev: ee712c8b3c32fedd6af0521d2e34ea655f8cd5ca) Signed-off-by: Vincent Kriek <vincent@coelebs.dev> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 4c89b061003a0f4143c6d3838e39fc2643edc8d6) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* devtool: modify: Catch git submodule error for go codeAnton Almqvist2024-06-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | One of the git submodule commands failed for source extracted for recipes using go.bbclass. The root cause is probably the path set up by go_do_unpack which makes S and gitroot not match. This patch does not fix the root problem, but at least it is no worse than before the git submodule support. The extracted source will still have two .git folders, one in S created by devtool and one in the go path which will contain the tru git history. [ YOCTO #15483 ] (From OE-Core rev: 1dc639353658496db5c5df802c0259e87fe2ca0f) Signed-off-by: Anton Almqvist <antonal@axis.com> Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit fe242408af40dd1f6e47d9b2b232bdc76756c80a) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* devtool: standard: update-recipe/finish: fix update localfile in another layerJulien Stephan2024-06-051-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to use devtool update-recipe/finish on another layer, with modified local file we have the following error: Traceback (most recent call last): File "<..>/poky/scripts/devtool", line 350, in <module> ret = main() ^^^^^^ File "<..>/poky/scripts/devtool", line 337, in main ret = args.func(args, config, basepath, workspace) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<..>/poky/scripts/lib/devtool/standard.py", line 1968, in update_recipe updated, _, _ = _update_recipe(args.recipename, workspace, rd, args.mode, args.append, args.wildcard_version, args.no_remove, args.initial_rev, dry_run_outdir=dry_run_outdir, no_overrides=args.no_overrides, force_patch_refresh=args.force_patch_refresh) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<..>/poky/scripts/lib/devtool/standard.py", line 1930, in _update_recipe updated, appendf, removed = _update_recipe_patch(recipename, workspace, srctree, crd, appendlayerdir, wildcard_version, no_remove, no_report_remove, initial_rev, dry_run_outdir, force_patch_refresh) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<..>/poky/scripts/lib/devtool/standard.py", line 1747, in _update_recipe_patch patchdir = param.get('patchdir', ".") ^^^^^^^^^ AttributeError: 'str' object has no attribute 'get' This was introduced when adding support for git submodules. No selftest case exists to catch this, so a selftest will be added in another commit. (From OE-Core rev: de7ca9f800e15e10271502da7e51e3ae08e0c85b) (From OE-Core rev: b4fb19df1746d04c9534feff58a9e534705d46df) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Jeff Harris <jefftharris@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* recipetool: Handle several go-import tags in go resolverSven Schwermer2024-05-231-14/+9
| | | | | | | | | | | | | | | | | | | | | When dynamically resolving go modules, the HTML page may contain several go-import meta tags. We must handle all and pick the correct one based on the module name. An example for such a behaviour is gonum.org/v1/gonum: <meta name="go-import" content="gonum.org/v1/exp git https://github.com/gonum/exp"> <meta name="go-import" content="gonum.org/v1/gonum git https://github.com/gonum/gonum"> <meta name="go-import" content="gonum.org/v1/hdf5 git https://github.com/gonum/hdf5"> <meta name="go-import" content="gonum.org/v1/netlib git https://github.com/gonum/netlib"> <meta name="go-import" content="gonum.org/v1/plot git https://github.com/gonum/plot"> <meta name="go-import" content="gonum.org/v1/tools git https://github.com/gonum/tools"> (From OE-Core rev: b198617a988d6eeef09b84e1009c0dc8fb55a9c5) Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 9c36a61e29359067165bddc7f2accdf2c4c8a761) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* recipetool: Handle unclean response in go resolverSven Schwermer2024-05-231-4/+7
| | | | | | | | | | | | | It appears that some go modules repond with a 404 error when trying to resolve them dynamically. The response body may still contain the go-import meta tag. An example for such behaviour is gonum.org/v1/gonum. (From OE-Core rev: d61934122cdc9f2d68f99e5e3363c3f1808e7782) Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 8f2e14ab6562a9a68819a960c66a258ea9dbe246) Signed-off-by: Steve Sakoman <steve@sakoman.com>
* scripts/oe-setup-build: write a build environment initialization one-liner ↵Alexander Kanavin2024-05-061-1/+10
| | | | | | | | | | | | | | | | | | | | | | | into the build directory With this, users no longer have to know where oe-init-build-env is relative to the build directory; that information is contained in the one liner and then it's possible to simply use that: . /path/to/build/init-build-env This will particularly help with initializing builds in unpacked build bundles, as users won't have to know where oe-init-build-env is in the bundle directory tree - similar to esdk initialization. (From OE-Core rev: 1cabdf287c2739accdab3a766df060f1bc802b63) (From OE-Core rev: 4bf3f11e39312cfce59d4652804faf0eec6b5ace) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
* devtool: standard: throws appropriate error if source is in detached HEADJulien Stephan2024-04-121-0/+2
| | | | | | | | | | | | | | | | | | | | | If source is in detached HEAD, we get the following error when using detvool finish command: [...] File "<...>/poky/scripts/lib/devtool/standard.py", line 1938, in _update_recipe bb.process.run('git checkout %s' % startbranch, cwd=srctree) File "<...>/poky/bitbake/lib/bb/process.py", line 189, in run raise ExecutionError(cmd, pipe.returncode, stdout, stderr) bb.process.ExecutionError: Execution of 'git checkout (HEAD detached at 9bbf87e)' failed with exit code 2: /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `git checkout (HEAD detached at 9bbf87e)' Check this and throws an appropriate error in this case (From OE-Core rev: d9c686b5ff9f591ec6b928ed539084c02df4c8a5) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* wic: bootimg-partition allow to set var to get boot filesAnibal Limon2024-03-261-2/+3
| | | | | | | | | | | | This is a generic functionality that takes a set of files and create a boot parition based on IMAGE_BOOT_FILES var, allow to sepcify the variable name so a BSP plugin can extend this and re-use the functionality. (From OE-Core rev: 3a2339455be29a6ff65c8c5f6865a4cd35dd7f63) Signed-off-by: Anibal Limon <anibal@limonsoftware.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bmaptool: now part of Yocto ProjectTrevor Woerner2024-03-051-1/+1
| | | | | | | | | | | | | The bmaptool (previously: bmap-tools, bmap-tool, bmaptool) has been moved to be under the Yocto Project umbrella and is now hosted at: github.com/yoctoproject/bmaptool [RP: Added a couple of missing renames] (From OE-Core rev: 7a036b1a1ec7dcd27dbe18d4c2e703bd2a8af182) Signed-off-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide-sdk prefer sources from workspaceAdrian Freihofer2024-02-273-6/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improve the previous commit: - log an error if some assumptions are not true - Use TARGET_DBGSRC_DIR variable - Do the same for ide none Why the additional source mapping is required: For example the cmake-example recipe refers to sources like this: ./recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-readelf \ -wi image/usr/bin/cmake-example | grep -B1 DW_AT_comp_dir ... <560> DW_AT_name : (indirect line string, offset: 0x1da): /usr/src/debug/cmake-example/1.0/oe-local-files/cpp-example.cpp ... Another example is powertop: ./recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-readelf \ -wi image/usr/sbin/powertop | grep -B1 DW_AT_comp_dir ... <561> DW_AT_name : (indirect line string, offset: 0x1da): /usr/src/debug/powertop/2.15/src/devlist.cpp ... For recipes with local files this works. The oe-local-files folder is not available in the rootfs-dbg and therefore the sources are first found in the workspace folder. GDB searches for source files in various places: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html However, for the powertop example the sources opened in the editor are from the rootfs-dbg instead of from the workspace. Bitbake calls the compiler with -fmacro-prefix-map=${S}=${TARGET_DBGSRC_DIR} where TARGET_DBGSRC_DIR defaults to "/usr/src/debug/${PN}/${PV}". A source map which maps the recipe specific path from TARGET_DBGSRC_DIR to the workspace fixes this. The already existing source map for /usr/src/debug applies for all other recipes. It finds the sources (read only) in the rootfs-dbg folder. (From OE-Core rev: 06601632c1879cb80276f9b36de91fb7808311a5) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide-sdk source mapping for vscodeEnguerrand de Ribaucourt2024-02-272-0/+2
| | | | | | | | | | | | | | | When launching the debug configuration, the source files from the debug rootfs were openened in the editor instead of the local workspace files. We add an exception to properly map them to the file being developed and compiled by the IDE integration. This also more closely matches what the user would expect compared to native development. This is also true for the devtool fallback mode. (From OE-Core rev: 24db2b8d0d7104960c1cdb2c7ee5216c830a6754) Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide-sdk launch.json per recipe onlyAdrian Freihofer2024-02-271-2/+8
| | | | | | | | | | | | | | | | If multiple recipes are processed at once, the launch.json and the tasks.json of the second recipe contains also the configurations for the binaries of the first recipe. Example: devtool ide-sdk powertop cmake-example oe-selftest-image generated a launch and a tasks configuration for the cmake-example recipe which also offers debugging the powertop binary. (From OE-Core rev: 63986b2c40d90fe96cdc6a46aa649efcf17f6ac2) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* wic: 'empty' plugin: fix typo in commentEnrico Jörns2024-02-271-1/+1
| | | | | | | (From OE-Core rev: 1a9013c3767d174a970d31e80748bc8d73af0dba) Signed-off-by: Enrico Jorns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* patchtest: provide further guidance for failed testcasesSimone Weiß2024-02-241-2/+2
| | | | | | | | | | | Cross-reference the wiki page on patchtest now that it is updated and contains more information how to address failed testcases. Adding it in patchtest only is enough as patchtest-send-result already points to the wikipage for failures. (From OE-Core rev: 51267f3c5d647fc6483ce6b597ed9e25c14bd425) Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide-sdk python 3.12 escapingAdrian Freihofer2024-02-242-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | scripts/lib/devtool/ide_sdk.py:709: SyntaxWarning: invalid escape sequence '\.' re_so = re.compile('.*\.so[.0-9]*$') scripts/lib/devtool/ide_plugins/__init__.py:87: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_start += "test -f \$TEMP_DIR/pid && exit 0; " scripts/lib/devtool/ide_plugins/__init__.py:88: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_start += "mkdir -p \$TEMP_DIR; " scripts/lib/devtool/ide_plugins/__init__.py:89: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_start += "%s --multi :%s > \$TEMP_DIR/log 2>&1 & " % ( scripts/lib/devtool/ide_plugins/__init__.py:91: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_start += "echo \$! > \$TEMP_DIR/pid;" scripts/lib/devtool/ide_plugins/__init__.py:94: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_stop += "test -f \$TEMP_DIR/pid && kill \$(cat \$TEMP_DIR/pid); " scripts/lib/devtool/ide_plugins/__init__.py:95: SyntaxWarning: invalid escape sequence '\$' gdbserver_cmd_stop += "rm -rf \$TEMP_DIR; " (From OE-Core rev: e8c64921de7206bf617fc42433286867ae3c931d) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide: define compilerPath for meson projectsEnguerrand de Ribaucourt2024-02-232-0/+4
| | | | | | | | | | | | | | The compile_commands.json file output by meson uses the compiler as if present in the $PATH. However, when using an IDE, the $PATH used by bitbake is not there. The vscode-cpptools now allows to define the compilerPath in addition to replace the one from compile_commands.json. (From OE-Core rev: d9f5c27c8beee07c7cbbed11f5d45058e7315846) Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide: vscode: Configure read-only filesEnguerrand de Ribaucourt2024-02-201-2/+9
| | | | | | | | | | | | | 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 <enguerrand.de-ribaucourt@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide_sdk: Use bitbake's python3 for generated scriptsEnguerrand de Ribaucourt2024-02-201-1/+1
| | | | | | | | | | | | | | | | | | 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 <enguerrand.de-ribaucourt@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool; add support for python_mesonpy classTim Orling2024-02-201-0/+4
| | | | | | | | | | | | | | | | | * 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 <tim.orling@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/oe/patch: Use git notes to store the filenames for the patchesPeter Kjellerstedt2024-02-192-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: Make use of oe.patch.GitApplyTree.commitIgnored()Peter Kjellerstedt2024-02-192-8/+2
| | | | | | | | | | 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>
* oe-setup-build: add a tool for discovering config templates and setting up ↵Alexander Kanavin2024-02-193-0/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* scripts/oe-setup-builddir: add support for configuration summariesAlexander Kanavin2024-02-191-0/+10
| | | | | | | | | 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>
* patchtest: add stronger indication for failed testsSimone Weiß2024-02-191-2/+2
| | | | | | | | | | | | | 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>
* scripts/oe-setup-layers: write a list of layer paths into the checkout's top dirAlexander Kanavin2024-02-191-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* oe-init-build-env: generate .vscode from templateAdrian Freihofer2024-02-191-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: _extract_source: Correct the removal of an old backup directoryPeter Kjellerstedt2024-02-181-6/+6
| | | | | | | | | Also correct the comment describing what is happening. (From OE-Core rev: 7d867753fba8d536bef4c72c7bea3f4ed26a1a95) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: standard: Add some missing whitespacePeter Kjellerstedt2024-02-181-12/+12
| | | | | | | | | Makes it a little bit easier when reading the code. (From OE-Core rev: 6a757f9648685448fd18507f6aaf4eed0a57579f) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ide-sdk make deploy-target quickerAdrian Freihofer2024-02-181-5/+38
| | | | | | | | (From OE-Core rev: 3b63e7adb5596739b846396304ff815859ce6a74) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: new ide-sdk pluginAdrian Freihofer2024-02-184-0/+1790
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new devtool ide plugin provides the eSDK and configures an IDE to work with the eSDK. In doing so, bitbake should be used to generate the IDE configuration and update the SDK, but it should no longer play a role when working on the source code. The work on the source code should take place exclusively with the IDE, which, for example, calls cmake directly to compile the code and execute the unit tests from the IDE. The plugin works for recipes inheriting the cmake or the meson bbclass. Support for more programming languages and build tools may be added in the future. There are various IDEs that can be used for the development of embedded Linux applications. Therefore, devtool ide-sdk, like devtool itself, supports plugins to support IDEs. VSCode is the default IDE for this first implementation. Additionally, some generic helper scripts can be generated with --ide none instead of a specific IDE configuration. This can be used for any IDE that supports calling some scripts. There are two different modes supported: - devtool modify mode (default): devtool ide-sdk configures the IDE to manage the build-tool used by the recipe (e.g. cmake or meson). The workflow looks like: $ devtool modify a-recipe $ devtool ide-sdk a-recipe a-image $ code "$BUILDDIR/workspace/sources/a-recipe" Work in VSCode, after installing the proposed plugins Deploying the artifacts to the target device and running a remote debugging session is supported as well. This first implementation still calls bitbake and devtool to copy the binary artifacts to the target device. In contrast to compiling, installation and copying must be performed with the file rights of the target device. The pseudo tool must be used for this. Therefore bitbake -c install a-recipe && devtool deploy-target a-recipe are called by the IDE for the deployment. This might be improved later on. Executing the unit tests out of the IDE is supported via Qemu user if the build tool supports that. CMake (if cmake-qemu.bbclass is inherited) and Meson support Qemu usermode. - Shared sysroots mode: bootstraps the eSDK with shared sysroots for all the recipes passed to devtool ide-sdk. This is basically a wrapper for bitbake meta-ide-support && bitbake build-sysroots. The workflow looks like: $ devtool ide-sdk --share-sysroots a-recipe another-recipe vscode where/the/sources/are If the IDE and the build tool support it, the IDE gets configured to offer the cross tool-chain provided by the eSDK. In case of VSCode and cmake a cmake-kit is generated. This offers to use the cross tool-chain from the UI of the IDE. Many thanks to Enguerrand de Ribaucourt for testing and bug fixing. (From OE-Core rev: 3f8af7a36589cd05fd07d16cbdd03d6b3dff1f82) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sstate-cache-management: fix regex for 'sigdata' stamp filesAndré Draszik2024-02-171-1/+1
| | | | | | | | | | | | | Given file names like 6.4.do_fetch.sigdata.821b6c62f9f2bd8b7e1378656b8319697a21f6f6e4a351f98dc325a18ef7ed0f, I'm pretty sure we want to match the dot here, not any character. Fixes: 2fa1b25d7485 ("sstate-cache-management: Rewrite in python") in oe-core Fixes: b723fcaac52f ("sstate-cache-management: Rewrite in python") in poky (From OE-Core rev: 64281de7e352aaf48aa8c60b68633c54471fe353) Signed-off-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>