linux/poky.git/scripts/lib/devtool, branch rocko-next

devtool/sdk.py: error out in case of downloading file failure

2018-08-15T09:22:46+00:00

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) (From OE-Core rev: 4b022a62998e38dbefe1f882bcb9a229485ac9da) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

devtool: standard: Expand SRCREV before using it in _update_recipe_srcrev

2017-10-16T22:52:44+00:00

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

scripts: drop True option to getVar calls

2017-09-26T10:05:01+00:00

Search made with the following regex: getVar ?$(.*), True$. (From OE-Core rev: b848c3cb495905605283c57c79f2ed8ca17758db) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie

devtool: ensure recipes devtool is working on are unlocked within the eSDK

2017-09-18T10:07:29+00:00

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

devtool: rework source extraction so that dependencies are handled

2017-09-18T10:07:29+00:00

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

devtool/standard: set a preferred provider when adding a new recipe with devtool

2017-09-13T21:07:42+00:00

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

devtool: upgrade: check that user has configured git properly

2017-09-11T16:30:30+00:00

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

devtool: status: Sort entries before printing

2017-09-11T16:30:28+00:00

Sorted entries are easier to read. (From OE-Core rev: d0a123ec564f6d36977e472f8bc63f9c050ee616) Signed-off-by: Ola x Nilsson Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: add: add explicit srcrev/branch options

2017-08-31T22:30:02+00:00

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

devtool: edit-recipe: fix regression

2017-08-31T22:30:02+00:00

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