summaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool
Commit message (Collapse)AuthorAgeFilesLines
* devtool: prevent starting git gc in backgroundTaras Kondratiuk2019-05-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devtool creates a git repository for extracted sources in a temporary directory and then moves it to a final destination after patching is done. Unfortunately devtool is not aware that some of its git operations may have caused git garbage collector to start in background. If timing is just right a repository move fails because GC is removing git objects while they are being moved. The issue was hit on Krogoth release, but the code that moves created git repository is still the same. Disable gc.autodetach to make GC run synchronously and block git until it is done. Traceback (most recent call last): File "<snip>/openembedded-core/scripts/devtool", line 342, in <module> ret = main() File "<snip>/openembedded-core/scripts/devtool", line 329, in main ret = args.func(args, config, basepath, workspace) File "<snip>/openembedded-core/scripts/lib/devtool/standard.py", line 352, in extract initial_rev = _extract_source(srctree, args.keep_temp, args.branch, False, rd) File "<snip>/openembedded-core/scripts/lib/devtool/standard.py", line 644, in _extract_source shutil.move(srcsubdir, srctree) File "/usr/lib/python2.7/shutil.py", line 299, in move copytree(src, real_dst, symlinks=True) File "/usr/lib/python2.7/shutil.py", line 208, in copytree raise Error, errors Error: [('/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/5e', '<snip>/build/grpc/grpc_src/.git/objects/5e', "[Errno 2] No such file or directory: '/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/5e'"), ('/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/57', '<snip>/build/grpc/grpc_src/.git/objects/57', "[Errno 2] No such file or directory: '/tmp/devtool5RXkuX/workdir/grpc-1.2.5/.git/objects/57'"), many git objects ... ] (From OE-Core rev: eae5caaf050f54a065e2654a60f55fda2c3afd95) Signed-off-by: Taras Kondratiuk <takondra@cisco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* correct do_patch for kernel bbappend in sdkYann CARDAILLAC2019-05-221-3/+1
| | | | | | | | | | | | | | | do_patch rule of SDK's workspace/appends/linux-*.bbhappend may fail if script are not written in Python that was the case with Phytec's BSP, the fix was to replace the do_patch rule with : do_patch[noexec]="1" when the file was generated in scripts/lib/devtool/standard.py (From OE-Core rev: e041812a84025a9ff9121efabc3805ff2dfe6375) Signed-off-by: Yann CARDAILLAC <yann.cardaillac@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: improve git repo checks before check_commits logicDan Dedrick2019-02-251-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check_commits logic assumes that both devtool-base and args.branch exist in the git repo that it is operating on. In order to prevent errors at that point it's best to first ensure that both of these refs actually exist. If they don't both exist then the check_commits logic should just be skipped, as it would be if the repo wasn't originally checked out by devtool. Previously if a user removed the args.branch branch from their devtool cloned repo this code would crash on adding the repo with -n. The crash would look like this: Traceback (most recent call last): File "/home/ddedrick/src/poky/scripts/devtool", line 344, in <module> ret = main() File "/home/ddedrick/src/poky/scripts/devtool", line 331, in main ret = args.func(args, config, basepath, workspace) File "/home/ddedrick/src/poky/scripts/lib/devtool/standard.py", line 812, in modify (stdout, _) = bb.process.run('git log devtool-base..%s' % branch, cwd=srctree) File "/home/ddedrick/src/poky/bitbake/lib/bb/process.py", line 178, in run raise ExecutionError(cmd, pipe.returncode, stdout, stderr) bb.process.ExecutionError: Execution of 'git log devtool-base..devtool' failed with exit code 128: fatal: ambiguous argument 'devtool-base..devtool': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' (From OE-Core rev: f13a3490fdb404bbd4c77e45b83540d6deec1358) (From OE-Core rev: ebd3c5e1534ba4ac2a6e97725f8d8650d4aa52a0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: remove duplicate overridesDan Dedrick2019-02-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of overrides. Previous to these changes it would find every override to SRC_URI and add it to the list. This would duplicate instances where SRC_URI is modified multiple times with the same override like: SRC_URI_append_foo += "file://0001-foo.patch" SRC_URI_append_foo += "file://0002-bar.patch" A bbappend might also overwrite a SRC_URI override, which would also cause multiple instances to occur. When there are multiple instances of the same override in DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating override branches. The failure occurs when attempting to create the same override branch a second time and looks like this: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: <module> 0001: *** 0002:devtool_post_patch(d) 0003: File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202, function: devtool_post_patch 0198: 0199: for override in extra_override_list: 0200: localdata = bb.data.createCopy(d) 0201: if override in default_overrides: *** 0202: bb.process.run('git branch devtool-override-%s %s' % (override, devbranch), cwd=srcsubdir) 0203: else: 0204: # Reset back to the initial commit on a new branch 0205: bb.process.run('git checkout %s -b devtool-override-%s' % (initial_rev, override), cwd=srcsubdir) 0206: # Run do_patch function with the override applied File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run 0174: if not stderr is None: 0175: stderr = stderr.decode("utf-8") 0176: 0177: if pipe.returncode != 0: *** 0178: raise ExecutionError(cmd, pipe.returncode, stdout, stderr) 0179: return stdout, stderr Exception: bb.process.ExecutionError: Execution of 'git branch devtool-override-foo devtool' failed with exit code 128: fatal: A branch named 'devtool-override-foo' already exists. (From OE-Core rev: 90f667db2219f04e6d61588cd61056d3d8da6d7d) (From OE-Core rev: 162be3d43f1d48a22b3aed32cc2f593355e5bf81) Signed-off-by: Dan Dedrick <ddedrick@lexmark.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix target-deploy --stripAdrian Freihofer2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fixup for: e1ba46109ea4be3d3b310abaf7f2da3c84a83930 devtool deploy-target --strip foo root@192.168.7.2 ended up with: Traceback (most recent call last): File "/home/user/bar_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ devtool", line 344, in <module> ret = main() File "/home/user/bar_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ devtool", line 331, in main ret = args.func(args, config, basepath, workspace) File "/home/user/bar_sdk/layers/poky/scripts/lib/devtool/ deploy.py", line 187, in deploy rd.getVar('base_libdir')) TypeError: strip_exbar() missing 1 required positional argument: 'd' (From OE-Core rev: bc349b2d99d74f6d7fb590fd97750e5ff8d6e6c4) (From OE-Core rev: fc5cd4b4b17fc932b987f66cbfc002345ee694b6) Signed-off-by: Adrian Freihofer <adrian.freihofer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* build.py: add clean option to 'devtool build' commandChen Qi2018-09-101-1/+6
| | | | | | | | | | | | | | | | | | Add -c (--clean) optiont to 'devtool build' command so that users could easily clean things up when using devtool. I encountered a problem about do_prepare_recipe_sysroot failure when using `devtool build' command and I found myself in a situation where I either have to use `bitbake' command to clean things up or use `rm' to remove the directories under ${WORKDIR}. So add a clean option as it would be helpful when users want to clean things up to prepare an environment for a clean build. (From OE-Core rev: 29d790cdeff19e520a35ec5902d6deaae8665492) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* logging: use warning instead warnChen Qi2018-07-264-16/+16
| | | | | | | | | | | | | | | | The warn method is deprecated. We should use the documented warning instead. Quoting from the python's official doc: """ Note: There is an obsolete method warn which is functionally identical to warning. As warn is deprecated, please do not use it - use warning instead. """ (From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/upgrade: fix the order of license checksum representationChen Qi2018-05-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most recipes in OE, beginline and endline are before md5 checksum. We should obey this tradition in devtool's upgrade. Otherwise, we might see meaningless change just because of the order change. e.g. -LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ - file://plugins/sudoers/redblack.c;beginline=1;endline=41;md5=805782a8466975716f8376b2be9aedde \ - file://lib/util/reallocarray.c;beginline=3;endline=16;md5=85b0905b795d4d58bf2e00635649eec6 \ - file://lib/util/fnmatch.c;beginline=3;endline=27;md5=67f83ee9bd456557397082f8f1be0efd \ - file://lib/util/getcwd.c;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/glob.c;beginline=6;endline=31;md5=5872733146b9eb0deb79e1f664815b85 \ - file://lib/util/snprintf.c;beginline=6;endline=34;md5=c82c1b3a5c32e08545c9ec5d71e41e50 \ - file://include/sudo_queue.h;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a" +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=cc4bf2366b059c9598e3947f885931ec \ + file://plugins/sudoers/redblack.c;md5=805782a8466975716f8376b2be9aedde;beginline=1;endline=41 \ + file://lib/util/reallocarray.c;md5=85b0905b795d4d58bf2e00635649eec6;beginline=3;endline=16 \ + file://lib/util/fnmatch.c;md5=67f83ee9bd456557397082f8f1be0efd;beginline=3;endline=27 \ + file://lib/util/getcwd.c;md5=449af4cc57fc7d46f42090608ba3e681;beginline=5;endline=27 \ + file://lib/util/glob.c;md5=5872733146b9eb0deb79e1f664815b85;beginline=6;endline=31 \ + file://lib/util/snprintf.c;md5=c82c1b3a5c32e08545c9ec5d71e41e50;beginline=6;endline=34 \ + file://include/sudo_queue.h;md5=449af4cc57fc7d46f42090608ba3e681;beginline=5;endline=27 \ + file://lib/util/inet_pton.c;md5=3970ab0518ab79cbd0bafb697f10b33a;beginline=3;endline=17 \ + " After this change, it becomes: -LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=cc4bf2366b059c9598e3947f885931ec \ file://plugins/sudoers/redblack.c;beginline=1;endline=41;md5=805782a8466975716f8376b2be9aedde \ file://lib/util/reallocarray.c;beginline=3;endline=16;md5=85b0905b795d4d58bf2e00635649eec6 \ file://lib/util/fnmatch.c;beginline=3;endline=27;md5=67f83ee9bd456557397082f8f1be0efd \ @@ -12,7 +12,8 @@ LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ file://lib/util/glob.c;beginline=6;endline=31;md5=5872733146b9eb0deb79e1f664815b85 \ file://lib/util/snprintf.c;beginline=6;endline=34;md5=c82c1b3a5c32e08545c9ec5d71e41e50 \ file://include/sudo_queue.h;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a" + file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a \ + " (From OE-Core rev: 6c5cc1b298be6aa1e9d378bc8349e11cbf17d300) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/sdk.py: error out in case of downloading file failureChen Qi2018-05-151-0/+3
| | | | | | | | | | | | | | | | It's possible that downloading file from updateserver fails. In this case, we should error out instead of continue. We have users reporting unexpected behavior of 'devtool sdk-update'. When an invalid url is supplied, e.g., `devtool sdk-update http://invalid', the program reports 'Note: Already up-to-date'. This is obviously not expected. We should error out in such case. (From OE-Core rev: 449564783dfb162536a2f772b3a8704973221e0f) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add --force-patch-refresh to 'modify' and 'finish' commandsAlexander Kanavin2018-03-111-9/+11
| | | | | | | | | | | | | | | | | | This is very useful for updating patch context so that any fuzz is eliminated. Simply issue: devtool modify <recipe> devtool finish --force-patch-refresh <recipe> <layer_path> Without this flag, devtool will not deem the commits in the workspace different to patches in the layer, even if the commits have different, up-to-date context line in them. (From OE-Core rev: 7e1d1887be8faaaab9996fca9a3fd750aeb7b62f) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: search: tweak help textPaul Eggleton2018-03-011-2/+2
| | | | | | | | | | | | | | * We now match on more than just target recipes, so don't specify that only target recipes are searched. * We're printing the SUMMARY value in addition to the name, so mention that so it's clear where that text is coming from. * Remind users that they should use quotes around the keyword to avoid shell expansion when using regular expressions. (From OE-Core rev: cc68971557fe065e59ff47657f650051eb85db3c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: search: also look in recipe cachePaul Eggleton2018-03-011-33/+63
| | | | | | | | | | | | | | | | | | | | | | | If pkgdata isn't present or is incomplete, then you get either a traceback or you don't see the results you were hoping for. The recipe cache that bitbake collects during startup contains some useful information for each recipe that we could search through as well, and we can access it easily using tinfoil's all_recipes() API function, so add some code that does that. (We still show a warning if pkgdata isn't present, as there are certain dynamic packages that are generated at packaging time that won't show up in the cache). One side-effect of this is that we will start showing non-target recipes - that's actually a good thing, since seeing those is useful, however we exclude nativesdk recipes when in the eSDK to avoid confusion since nativesdk isn't directly applicable there. Fixes [YOCTO #12356]. (From OE-Core rev: b8406383886d09a80a9a002150dcf364fa9902d7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: don't specify ssh/scp port unless user doesPaul Eggleton2018-03-011-8/+4
| | | | | | | | | | | | | If the user doesn't specify a port then we should avoid specifying one on the ssh/scp command line in case the user has configured one for the host they are connecting to, which was being overridden unnecessarily. Fixes [YOCTO #12381]. (From OE-Core rev: f1020eef09fada7ef2231d5528576553f3f6bfe1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: finish: fix erroneously creating bbappend for relative pathsPaul Eggleton2018-03-011-3/+1
| | | | | | | | | | | | | | | After OE-Core rev 5e3fe00a0233d563781849a44f53885b4e924a9c we call os.path.abspath() on the original layer path, but we later compare that to the destination layer path. If that layer path isn't absolute but is effectively the same path, it should be writing to the original recipe but because we weren't making it absolute we were writing a bbappend instead. Call os.path.abspath() on the destination path as well to avoid that. (From OE-Core rev: a85a78dcf226d160e9b504bfa67b306a9175ac29) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: delete bbappend file if _check_preserve() doesn'tPaul Eggleton2018-03-011-0/+7
| | | | | | | | | | | | If the .devtool_md5 file doesn't contain a reference to the bbappend file (e.g. because devtool was interrupted before it could write that out) then _check_preserve() won't delete it, so we need to delete it separately because otherwise the recipe won't actually be reset. (From OE-Core rev: 751d27600a3df18d96baaa48696acf33ee964bec) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix poor handling of upgraded BBCLASSEXTENDed recipesPaul Eggleton2018-03-011-1/+5
| | | | | | | | | | | | | | | Fix two aspects of handling BBCLASSEXTENDed targets (e.g. openssl-native) that have been run through "devtool upgrade": * Fix recipe name not showing up in "devtool status" * Fix "devtool reset" not deleting empty directories under the recipe directory within the workspace, which may lead to problems if you subsequently run "devtool upgrade" on the same target again (From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: set up git repos so that singletask.lock is ignoredPaul Eggleton2018-02-061-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | singletask.lock is written out while certain tasks execute for recipes that have externalsrc.bbclass enabled - this includes recipes in devtool's workspace. It appears that there's a race where singletask.lock will be there one minute and then when we try to get the file checksum of it (since we want to know if anything in the source tree has changed) it will be gone, and git chokes. To fix that, add singletask.lock to .git/info/exclude in the repository, regardless of whether we created the repository or not. In any case singletask.lock should never be tracked by git, so this is a good thing to be doing for that reason as well. This fixes oe-selftest failures in test_devtool_modify that we've seen on the Yocto Project autobuilder: bb.data_smart.ExpansionError: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception CalledProcessError: Command '['git', 'add', '-A', '.']' returned non-zero exit status 128. Note that this only fixes this issue for devtool; if you are using externalsrc independently of devtool there's a chance this will still be an issue unless you add singletask.lock to your .gitignore. (From OE-Core rev: 334ba846c795fc0d8c73ce05a1b0882739c86650) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: rename the suggested license change tag to 'License-Update:'Alexander Kanavin2018-01-181-2/+2
| | | | | | | (From OE-Core rev: 3905ae20330f204f3c8997e2d5aaf15dcf5a860c) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add license checksum change handling to 'devtool upgrade'Alexander Kanavin2017-12-181-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, 'devtool upgrade' will now do these things: 1) determine if any of the license checksums need updating; if so, write the new checksums into the LIC_FILES_CHKSUM value in the recipe that is written to the workspace; 2) print a notice to the standard output: NOTE: New recipe is /home/ak/development/poky/build/workspace/recipes/puzzles/puzzles_git.bb NOTE: License checksums have been updated in the new recipe; please refer to it for the difference between the old and the new license texts. 3) and the cool part: devtool will create a diff of the old and new licenses, and write the diff into the workspace recipe as a comment, like this: ====== FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'. The following is the difference between the old and the new license text. Please update the LICENSE value if needed, and summarize the changes in the commit message via 'License-checksum-change:' tag. (example: 'License-checksum-change: copyright years updated.') The changes: --- LICENCE +++ LICENCE @@ -1,8 +1,9 @@ This software is copyright (c) 2004-2014 Simon Tatham. Portions copyright Richard Boulton, James Harvey, Mike Pinna, Jonas -Klker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd -Schmidt, Steffen Bauer, Lennard Sprong and Rogier Goossens. +Kölker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd +Schmidt, Steffen Bauer, Lennard Sprong, Rogier Goossens and Michael +Quevillon. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files ====== (From OE-Core rev: ccb37f9e81eb78ed0eb2a238d7c3e196db9b2f72) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: provide useful defaults for version/commit when upgrading recipesAlexander Kanavin2017-12-181-4/+12
| | | | | | | | | | Specifically, 'devtool upgrade' will use the latest upstream release if available or latest commit if upstream never makes releases. (From OE-Core rev: 45b4242b105ad36e94ae15a96d588a58b917b8e8) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add a 'latest-version' commandAlexander Kanavin2017-12-181-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | This command queries the upstream server for what the latest release is and prints the output; it is a much neater way to find out these things than fumbling with distrodata, 'bitbake -c checkpkg' and awkward to read csv output in a file. Examples: python3 (tarballs): NOTE: Current version: 3.5.3 NOTE: Latest version: 3.6.3 rpm (git): NOTE: Current version: 4.13.90 NOTE: Latest version: 4.14.0 NOTE: Latest version's commit: da3720f62e57648fb1dc2a632744d38866139971 puzzles (git without version tags): NOTE: Latest commit: ee8ea9b9785964694cb2b3ad77c3fb2460f49510 (From OE-Core rev: e8f5b5cc25ce7a9882f21473cefc47edcebf77d4) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: implement conditional patch handlingPaul Eggleton2017-11-112-26/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have a recipe that uses overrides to conditionally extend SRC_URI to add additional patches, then you will often need to update those patches if you're making other changes to the source tree (for example if you're upgrading the underlying source). Make this possible with devtool by creating devtool-override-* branches for each override that conditionally appends/prepends SRC_URI, and have devtool update-recipe / finish check each branch out in turn and update the corresponding patches. A current example of a recipe that does this is the quota recipe - it applies an additional patch if musl is the selected C library (i.e. libc-musl is in OVERRIDES). Note that use of this functionality does require some care - in particular, updates to patches that appear on the main branch (named "devtool" by default) should be made there and not only on one of the specific devtool-override-* branches that are created for each override. The recommended procedure is to make the changes you want to make to the main branch first, then check out and rebase each devtool-override-* branch, testing each one by activating the corresponding configuration, and then finally run devtool finish. Fixes [YOCTO #11516]. (From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: finish: add dry-run optionPaul Eggleton2017-11-111-71/+199
| | | | | | | | | | | | | | | If you're not sure what changes devtool finish is going to make, or you're not sure you're finished with your modifications, it is useful to be able to see what devtool finish is going to do beforehand, so add a -N/--dry-run option to make that possible. (It's also very useful for debugging devtool finish itself.) (From OE-Core rev: 05f2d5d2ce00c53825ccea5cd9c2262f9d27a638) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: finish: improve reporting for removed filesPaul Eggleton2017-11-111-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | If a file is going to be effectively removed from the destination by devtool finish, we should report that rather than just reporting that we're removing files from the workspace. This is a little tricky because the way we actually operate when finishing is to: (1) remove all original files (as recorded by devtool upgrade, if that was used) (2) as part of updating the recipe file, remove the files from next to the new recipe (i.e. in the workspace for an upgrade, real recipe otherwise) corresponding to commits not in the git tree (3) copy over remaining files from the workspace to the destination To report the files removed with respect to what was originally there, we need to swap steps 1 and 2 so we can see what no longer exists after the deletion, and suppress the reporting currently done in step 2 - however, we still want to report removal in step 2 for the non-upgrade case, so the latter is conditional. (From OE-Core rev: db1d663507509cac9d97d7c96ac8590478767ba2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: show a better error message if meta-files aren't foundPaul Eggleton2017-11-111-4/+7
| | | | | | | | | | | | If the files that the devtool-source class is supposed to create in the source tree aren't found in the temporary directory then we know that the class hasn't worked properly - say that explicitly. (From OE-Core rev: 4621152509c037532b133e5e6d5b73bda7ddb602) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: reformat --no-patch warning messagePaul Eggleton2017-11-111-4/+2
| | | | | | | | | | | | * Only log one warning message instead of one per line * Be a bit more verbose * "if list" is more pythonic than "if len(list)" (From OE-Core rev: 2d11e9e6e73648c1cb514c0c10111c7886acae78) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: automatically handle changes to source subdirectoryPaul Eggleton2017-11-112-9/+28
| | | | | | | | | | | | | | | | | If the directory where the source code extracts to changes (for example, when upgrading iucode-tool from 1.5 to 2.1.1, the subdirectory in the tarball changed from "iucode_tool-${PV}" to "iucode-tool-${PV}") then handle this automatically. Also handle when it changes to match the default S value (i.e. "${WORKDIR}/${BP}") in which case we just drop setting S in the recipe. Fixes [YOCTO #10939]. (From OE-Core rev: d29881a652bf03627d257a1eac5f02ec17315b8b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: show messages before source extraction stepsPaul Eggleton2017-11-111-0/+2
| | | | | | | | | | Give the user a little more insight into what's being done. (From OE-Core rev: 9cf2089bd22b9fc4eb0eec8d4924e44519412dad) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: handle recipes that use named SRC_URI checksumsPaul Eggleton2017-11-111-13/+40
| | | | | | | | | | | | | | | | | | | | | devtool upgrade did not properly handle setting SRC_URI checksums for recipes that use named SRC_URI entries and also use those names in the SRC_URI checksums. A further complication was where the name contained an expression that changed with the version e.g. ${PV} (probably quite rare, but the dnsmasq recipe in meta-networking is currently one such recipe.) All of these are now handled properly. Additionally, drop the _get_checksums() function that wasn't being called from anywhere in the code. Note that this now turns nowrap_vars in recipeutils.py to be a list of regexes, hence things such as [ and ] need to be appropriately escaped. (From OE-Core rev: c914a5e1ad6d96e316746222e5d42f2ba9110060) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: finish: fix "layer not in bblayers.conf" warning when path specifiedPaul Eggleton2017-11-111-2/+4
| | | | | | | | | | | | | | | | | devtool finish will check if the destination layer is part of bblayers.conf so that we avoid the user getting confused about the recipe vanishing from their configuration if it isn't. devtool finish also accepts a path underneath a layer so that you have a bit more control over where it ends up. However if you used a path underneath a layer then it wasn't converting this to the base of the layer before checking it against BBLAYERS, thus the warning was being shown erroneously in that case. (From OE-Core rev: ab1b8d55e551fea3e8656aab7a786d1bfec62d0f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: finish: ensure repository is clean before proceedingPaul Eggleton2017-11-112-2/+32
| | | | | | | | | | | | | | | | | | If the git repository for a recipe in the workspace has uncommitted changes in it then it's possible that the user has forgotten to commit something, so check and exit if there are any. Provide a -f/--force option to continue in the case where the uncommitted changes aren't needed. Separately, if the repository is in the middle of a rebase or git am / apply then error out (without the opportunity to force) since the user really needs to sort this out before finishing. (From OE-Core rev: bfebd18982c0c82ef2da63ec8f22175c93b2e308) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: print source tree base pathPaul Eggleton2017-11-111-5/+5
| | | | | | | | | | | | | If S points to a subdirectory of the source rather than the "base" of the source tree then print that rather than the subdirectory path when telling the user they need to remove the source tree, since that is the directory that they will need to remove. (From OE-Core rev: 9e8808099046478e98c6cf1903dc6787d69132fc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: make find-recipe and edit-recipe always work with any recipePaul Eggleton2017-11-111-12/+14
| | | | | | | | | | | | | | After some reconsideration I think it's a bit annoying for users to be forced to use an option to work with recipes where the file isn't in the workspace, so let's just have these commands check the workspace first for the recipe, and if it isn't there then load the cache and get it that way. (From OE-Core rev: 46683c61069a386658676a79d797062404bf1140) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: show some warnings for upgrade versionsPaul Eggleton2017-11-113-3/+23
| | | | | | | | | | | | | | | | * Show a warning in devtool upgrade if the version is less than the current version suggesting that the user may need to bump PE in the recipe * Show a warning in devtool add and devtool upgrade if the version looks like a pre-release version suggesting using a version number that won't mess up the progression when you come to upgrade to the final release version. (From OE-Core rev: 92c4d9be9ed365c449ea1ac5a18ddb15e4a36b2d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix handling of oe-local-files when source is in a subdirectoryPaul Eggleton2017-11-111-9/+15
| | | | | | | | | | | | | | | | | | If S points to a subdirectory of the source rather than the "base" of the source tree then we weren't handling the oe-local-files directory properly - it got extracted to the base of the tree but devtool update-recipe and devtool finish assumed it would be under S which would be the subdirectory, thus it would be missing and devtool would assume the files had been deleted and remove them from the recipe. Record the base of the source tree in the bbappend and read it into the in-memory workspace so we can use that to find out where oe-local-files should be found. (From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: improve performance and show progress when adding filesPaul Eggleton2017-11-111-2/+9
| | | | | | | | | | | | | | | | | | | | | | | When devtool upgrade is upgrading to a new version where the source is fetched as an archive (e.g. a tarball), we create a single commit in the git repository that is the upgrade from the old version to the new. We do this by extracting the old source, committing it, deleting all files, copying in the new files, running git add on each new/changed/deleted file, and then committing the result. When a lot of files have changed in an upgrade (such as QEMU 2.8.1.1 -> 2.10.0) the penultimate step of running git add it can take quite a long time; in order to reduce this and show some feedback to the user, run git add with batches of 100 files at once and also show a progress bar. In a local test with the aforementioned QEMU upgrade it took the time down from over 7 minutes down to about 13 seconds. Fixes [YOCTO #11948]. (From OE-Core rev: 8b184f6c874b60324ee107af53853687173d3434) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: fix not committing deleted files with older git versionsPaul Eggleton2017-11-111-1/+1
| | | | | | | | | | | | | | With versions of git older than 2.0, "git add" on a deleted file (i.e. in this case a file that was removed between versions) will not add the delete to be committed by default, with the result that the rebase of patches on top of the new branch will fail. We need to use the -A option in order to force that for older git versions. (From OE-Core rev: c7f4c9f050c11c0de7fcf5badcc19a8fbc6428cf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: fix accidentally swapped parametersPaul Eggleton2017-11-111-1/+1
| | | | | | | | | | | | | | | | It appears that when fixing the signature unlocking in OE-Core commit 4e9a0be32fc30fb87d65da7cd1a4015c99533aff I swapped the parameters here and did not test it within the eSDK (it does nothing outside of the eSDK) resulting in a TypeError when devtool upgrade was used in the eSDK. Swap the parameters around to the correct ordering. Fixes [YOCTO #12285]. (From OE-Core rev: 05e2c4ada7083f40866846a21fe76c852f1dfefe) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: standard: Expand SRCREV before using it in _update_recipe_srcrevPeter Kjellerstedt2017-10-161-1/+1
| | | | | | | | | | | | | | | | If SRCREV contains a variable reference, any devtool command that would try to update it would fail. E.g., if SRCREV = "R${PV}", then devtool finish without having committed any changes would fail with: oe.patch.CmdError: Command Error: 'sh -c 'git format-patch R${PV} -o /tmp/oepatchb_doareb -- .'' exited with 0 Output: fatal: bad revision 'R' (From OE-Core rev: 094499c819722ad698ccb64ec65dd439b211c31c) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: drop True option to getVar callsMing Liu2017-09-261-4/+4
| | | | | | | | | Search made with the following regex: getVar ?\((.*), True\). (From OE-Core rev: b848c3cb495905605283c57c79f2ed8ca17758db) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ensure recipes devtool is working on are unlocked within the eSDKPaul Eggleton2017-09-183-11/+56
| | | | | | | | | | | | | | | | | | | | | | | | | Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: rework source extraction so that dependencies are handledPaul Eggleton2017-09-182-147/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since it was first implemented, devtool's source extraction (as used by the devtool modify, extract and upgrade subcommands) ignored other recipe dependencies - so for example if you ran devtool modify on a recipe that fetches from svn or is compressed using xz then it would fail if those dependencies hadn't been built first. Now that we can execute tasks in the normal way (i.e. tinfoil.build_targets()) then we can rework it to use that. This is slightly tricky in that the source extraction needs to insert some logic in between tasks; luckily we can use a helper class that conditionally adds prefuncs to make that possible. Some side-effects / aspects of this change worth noting: * Operations are a little slower because we have to go through the task dependency graph generation and other startup processing. There's not really any way to avoid this though. * devtool extract didn't used to require a workspace, now it does because it needs to create a temporary bbappend for the recipe. (As with other commands the workspace be created on the fly if it doesn't already exist.) * I want any existing sysroot files and stamps to be left alone during extraction since we are running the tasks off to the side, and especially devtool extract should be able to be used without touching these. However, this was hampered by the automatic removal process in sstate.bbclass triggered by bb.event.ReachableStamps when the task signatures change, thus I had to introduce a way to disable this removal on a per-recipe basis (we still want it to function for any dependencies that we aren't working on). To implement this I elected to use a file written to tmp/sstate-control which gets deleted automatically after reading so that there's less chance of stale files affecting future sessions. I could have used a variable but this would have needed to be whitelisted and I'd have to have poked its value in using the setVariable command. Fixes [YOCTO #11198]. (From OE-Core rev: 830dbd66992cbb9e731b48d56fddf8f220349666) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/standard: set a preferred provider when adding a new recipe with devtoolJuan M Cruz Alcaraz2017-09-131-0/+42
| | | | | | | | | | | | | | | | | | | | A recipe added with "devtool add" requires to be able to take precedence on recipes previously defined with PREFERRED_PROVIDER. By adding the parameter "--provides" to "devtool add" it is possible to specify an element to be provided by the recipe. A devtool recipe can override a previous PREFERRED_PROVIDER using the layer configuration file in the workspace. E.g. devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl [YOCTO #10415] (From OE-Core rev: adeea2fe6895898a5e6006e798898f0f5dabd890) Signed-off-by: Juan M Cruz Alcaraz <juan.m.cruz.alcaraz@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: check that user has configured git properlyPaul Eggleton2017-09-111-1/+26
| | | | | | | | | | | | | | | | | | | If user.name or user.email haven't been set then git rebase can't really work properly. Check that the user has set these and error out if not. (Elsewhere we are relying on OE's git patch functionality which forces a dummy OE value - that's OK there as it's completely under OE's control and therefore it's OK for a dummy OE user to be the committer, but here the rebase may require intervention so it's reasonable to have the user's actual name and email on the operation.) Fixes [YOCTO #11947]. (From OE-Core rev: 129a3be07e272013be2db17552c13b4d8cc2cf6e) (From OE-Core rev: 802829f1c38d8c5eee11ba1d9ddd37cf02597f6e) Signed-off-by: paul <paul@peggleto-mobl.ger.corp.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: status: Sort entries before printingOla x Nilsson2017-09-111-1/+1
| | | | | | | | | | Sorted entries are easier to read. (From OE-Core rev: d0a123ec564f6d36977e472f8bc63f9c050ee616) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: add explicit srcrev/branch optionsPaul Eggleton2017-08-311-2/+15
| | | | | | | | | | | | | | | | At the moment when fetching source from a git repository you have to know that you can specify the revision and branch in the URL with ';rev=' and ';branch=' respectively, and you can also get thrown off by the shell splitting on the ; character if you forget to surround the URL in quotes. Add explicit -S/--srcrev and -B/--srcbranch options (consistent with devtool upgrade) to make this easier for the user to discover and use. (The rev and branch URL parameters will continue to work, however.) (From OE-Core rev: 2d86cac853d6daa496c0315a5cb0662ebf1165b0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: edit-recipe: fix regressionPaul Eggleton2017-08-311-4/+11
| | | | | | | | | | | | | | OE-Core commit 5a16b3c804c5eca331a1c08a7ce31a54909af105 attempted to use the same function to get the path to a recipe as the new "find-recipe" command it implemented, except that cannot work because (a) it didn't return anything and (b) event if it had tried, a command function can only return an exit code and we don't want that for find-recipe if it succeeded. Split out a separate reusable function for both commands. (From OE-Core rev: d5191840212adbf480961ba6fc68e1ab17e5a77a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: workaround for recipes which apply patches conditional ↵Paul Eggleton2017-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | upon class If we're upgrading a recipe that appends additional patches for, say, class-native, and we're just upgrading the target variant, then when we copied the recipe into the workspace we skipped copying the additional patches for the native variant. This caused warnings because the workspace recipe is preferred. Look at SRC_URI for all variants when copying files to work around this. More work is needed to make it easier to work with recipes that use BBCLASSEXTEND where you need to build more than one variant at once, but this at least fixes the immediate ugliness. (From OE-Core rev: 56bf5e93358187e31160d7893f57906bb3dc7ad7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: fix handling of non-absolute pathsPaul Eggleton2017-08-311-0/+3
| | | | | | | | | | | | | | | | If your BBLAYERS has non-absolute paths in it (e.g. "${COREBASE}/../something") then none of the paths matched in copy_recipe_files() with the result that no files got copied and you ended up with an error later on because the recipe file couldn't be found at the destination. Fix this as well as adding an explicit check to see if no files got copied - error out earlier if so. Fixes [YOCTO #10981]. (From OE-Core rev: 3861486ad06f90c8644ebab119bbc5ddb9e693ca) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: update-recipe: ensure patches get deleted in srcrev modePaul Eggleton2017-08-311-1/+2
| | | | | | | | | | | | | | | | Patches that we identify as having been "deleted" (i.e. patches in SRC_URI that no longer appear in the git tree) need to be dropped even if we're updating in srcrev mode. This fixes the case where HEAD of the git tree is valid upstream (i.e. no extra commits), but there are patches left over in the recipe, e.g. when we do devtool upgrade and then all of the commits rebased on top of the new branch get skipped. Fixes [YOCTO #11972]. (From OE-Core rev: 350f83dc1e317aeb93539f13966caca6d894f569) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-07 02:03:54 +0000