linux/poky.git/scripts/lib/devtool/standard.py, branch rocko-18.0.4

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

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: 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: update-recipe: ensure patches get deleted in srcrev mode

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

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

devtool: append md5sum only if not already present

2017-08-23T07:47:02+00:00

In case the proposed md5sum to be appended to the .devtool_md5 file is already present, do not append it. (From OE-Core rev: f958c5cba3b0d24ca696b2b707857009c9a7b5b8) Signed-off-by: Leonardo Sandoval Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: fix handling of errors during task execution

2017-08-09T08:24:15+00:00

* If an error is logged while executing a task, we need to ensure we exit instead of assuming everything went OK. * If we receive CookerExit, the server is shutting down and we need to stop waiting for events and probably exit (knotty does this). This will occur if an exception or bb.fatal() happens during an event handler. This fixes a couple of issues highlighted when using devtool upgrade or modify on a non-supported recipe with intel-iot-refkit together with bitbake master, but I'd be very surprised if it were hard to reproduce in other scenarios. (From OE-Core rev: 65e644368fc9c294af96906528ee0cf30305e0a6) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: standard: enable options for PREMIRRORS and MIRRORS

2017-07-21T21:51:37+00:00

Since we have provide an option to manually enable PREMIRRORS and MIRRORS in recipetool, we need to make sure devtool is having the same options as devtool uses recipetool in creating new recipes. (From OE-Core rev: 198bddeb928a318c3ad168bcb4f83b5cd9a604fb) Signed-off-by: Chang Rebecca Swee Fun Signed-off-by: Ross Burton Signed-off-by: Richard Purdie