Mirror of git.yoctoproject.org/poky https://git.enea.com/cgit/linux/poky.git/atom?h=yocto-2.2.1 2016-10-05T09:10:11+00:00 2016-10-05T09:10:11+00:00 Paul Eggleton paul.eggleton@linux.intel.com 2016-10-04T09:31:16+00:00 urn:sha1:18caacae069a025662fcdd96b846857fc3107e41 If the user runs devtool add on an npm:// URL (or source tree that uses node.js), and npm is not available, just build nodejs-native instead of telling the user they need to do it; if that fails because there isn't any such recipe (which would be the default, since it's not in OE-Core) then produce a slightly more readable error message hinting at what the user needs to do. Note that this forces the use of nodejs-native rather than npm on the host - this makes sense for two reasons: (1) we need it to be compatible with nodejs for the target, and (2) we have to have a recipe for that anyway, so allowing you to avoid having a recipe for the native version isn't really beneficial. There's a bit of a hack in here in order to allow this - for node.js sources that aren't fetched via npm we don't know that they are that until we've fetched and unpacked them, by which time we're inside recipetool and have an active tinfoil instance that will prevent bitbake being run. To avoid this being an issue, we allow recipetool to get to the point where we know we need npm and then exit with a specific exit code, at which point devtool can try to build it and then if that succeeds, it will re-execute recipetool. This is definitely not ideal, but it can't really be refactored and done properly until we do the tinfoil2 refactoring; in the mean time though we still want to be helpful to the user. Fixes [YOCTO #10337]. (From OE-Core rev: f40662bde5aab158c4e4c3c3ff5e68665a4194a5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-09-03T22:45:52+00:00 Paul Eggleton paul.eggleton@linux.intel.com 2016-08-29T08:40:38+00:00 urn:sha1:4b4387455c62cf19fa3d215a11b5d0b1211d4570 When using PATCHTOOL = "git", the user of the system is not really the committer - it's the build system itself. Thus, specify "dummy" values for username and email instead of using the user's configured values. Various parts of the devtool code that need to make commits have also been updated to use the same logic. This allows PATCHTOOL = "git" and devtool to be used on systems where git user.name / user.email has not been set (on versions of git where it doesn't default a value under this circumstance). If you want to return to the old behaviour where the externally configured user name / email are used, set the following in your local.conf: PATCH_GIT_USER_NAME = "" PATCH_GIT_USER_EMAIL = "" Fixes [YOCTO #8703]. (From OE-Core rev: 765a9017eaf77ea3204fb10afb8181629680bd82) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-08-18T09:07:23+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2016-08-16T17:00:13+00:00 urn:sha1:189371f8393971d00bca0fceffd67cc07784f6ee Unfortunately to implenent multiconfig support in bitbake some APIs had to change. This updates code in OE to match the changes in bitbake. Its mostly periperhal changes around devtool/recipetool [Will need a bitbake version requirement bump which I'll make when merging] (From OE-Core rev: 041212fa37bb83acac5ce4ceb9b7b77ad172c5c3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-07-12T22:10:15+00:00 Paul Eggleton paul.eggleton@linux.intel.com 2016-07-10T23:07:56+00:00 urn:sha1:5c91537ab250e823b362bf5cc94760d26c6a4429 Certain recipes cannot be used with devtool extract / modify / upgrade - usually because they don't provide any source. Return a specific exit code (4) so that scripts such as scripts/contrib/devtool-stress.py know the difference between this and a genuine failure. (From OE-Core rev: ffd295fed4ab81fc0bd00bb145ef4d72c49584bf) 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> 2016-06-03T12:13:29+00:00 Ed Bartosh ed.bartosh@linux.intel.com 2016-06-02T10:13:02+00:00 urn:sha1:cdff6bc0c154a5d58a6e6892979af4f99d5a0d74 (From OE-Core rev: 4b544ff388497cac82b0585f237900595523e1cb) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-06-02T07:24:01+00:00 Ed Bartosh ed.bartosh@linux.intel.com 2016-05-18T18:57:23+00:00 urn:sha1:3ee70cb7259aad3b53e51884ec5b9122e804d77e Moved call of decode('utf-8') as close as possible to call of subprocess API to avoid calling it in a lot of other places. Decoded binary data to utf-8 where appropriate to fix devtool and recipetool tests in python 3 environment. (From OE-Core rev: 30d02e2aa2d42fdf76271234b2dc9f37bc46b250) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-06-02T07:24:01+00:00 Ed Bartosh ed.bartosh@linux.intel.com 2016-05-18T18:52:33+00:00 urn:sha1:ed7abe6b9a2ff81d320e7c63841487d37e61b5a5 Python 3 doesn't have basestring type as all string are unicode strings. (From OE-Core rev: e8cfab060f4ff3c4c16387871354d407910e87aa) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-06-02T07:24:01+00:00 Ed Bartosh ed.bartosh@linux.intel.com 2016-05-18T18:39:44+00:00 urn:sha1:7eab022d4b484aec40998f95835ba46c5da168cf Replaced iteritems -> items, itervalues -> values, iterkeys -> keys or 'in' (From OE-Core rev: 25d4d8274bac696a484f83d7f3ada778cf95f4d0) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-01-26T18:05:14+00:00 Paul Eggleton paul.eggleton@linux.intel.com 2016-01-26T02:53:54+00:00 urn:sha1:89a7ed5b67ca61c24abef07045e781cae892884d When you need to set EXTRA_OECONF for a recipe, you need to know what options the configure script actually supports; the configure script however is only accessible from within a devshell and (at least in the case of autotooled software fetched from an SCM repository) may not actually exist until do_configure has run. Thus, provide a "devtool configure-help" subcommand that runs the configure script for a recipe with --help and shows you the output through a pager (e.g. less), prefaced by a header describing the current options being specified. There is basic support for autotools, cmake and bare configure scripts. The cmake support is a little hacky since cmake doesn't really have a concise help option that lists user-defined knobs (without actually running through the configure process), however that being a design feature of cmake there's not much I can think of to do about that at the moment. (From OE-Core rev: 0e5d84d9705091b338000ef02720cfa090f76888) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2016-01-11T15:41:46+00:00 Paul Eggleton paul.eggleton@linux.intel.com 2016-01-06T11:15:55+00:00 urn:sha1:b2fe2a8fdc90f1945b9b3184b13b8d5e3e844e2e It's logical that you would want to build BBCLASSEXTENDed items separately through devtool build, so simply allow that - we're just passing the name verbatim to bitbake, so all it means is adjusting the validation. (From OE-Core rev: 25dc5ac42c9da53c01416e7fdcc819d729281133) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>