summaryrefslogtreecommitdiffstats
path: root/scripts/lib/recipetool
Commit message (Collapse)AuthorAgeFilesLines
* recipetool: always use python 3 in recipe creationAlexander Kanavin2019-12-301-13/+4
| | | | | | | (From OE-Core rev: 59e63a2d22988ef11fe36200692b967b67ca8641) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix devtool upgrade with reproducible_builds classPaul Eggleton2019-11-211-3/+1
| | | | | | | | | | | | | | | | | | If the reproducible_build class is inherited then there may be a "source-date-epoch" subdirectory in a fetched source tree; devtool upgrade was not expecting that in the upgraded source. Take a small snippet of code from recipetool create which already handles this, and make it a shared function that can be used in both places. Additionally, fix an assumption that the source is always in a subdirectory in the cleanup code that blocked debugging this. [YOCTO #13635] (From OE-Core rev: 0d642861cd9cf034b8d4951433980addc215d4fd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool/create: Fix to work with reproducible_buildsRichard Purdie2019-11-211-1/+1
| | | | | | | | | | The extra diretory created by reproducibile_builds was confusing recipetool and hence devtool. Ignore this directory to restore the correct behaviour and allow it to work with the class. (From OE-Core rev: 188ba30ef290efab6d5a9b95fba8e991b779ab33) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: add MD5 hash for the line-wrapped MPL-1.1 licenseRoss Burton2019-07-111-0/+1
| | | | | | | (From OE-Core rev: d2755523d339a4eba7a034bdef5563657609f563) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: ignore zero-length setup.py filesPaul Eggleton2019-07-031-2/+7
| | | | | | | | | | | | | | | If a setup.py file exists it ought to have something in it before we consider the source tree to be a Python module and treating it as such. (A counter-example is https://www.bro.org/downloads/binpac-0.50.tar.gz - it's not clear why this has a zero-length setup.py in it but we should pay no attention to it.) Fixes [YOCTO #12923]. (From OE-Core rev: 548a5c8f42c6ac1b0f7962926d05276e71505678) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package: Build pkgdata specific to the current recipeRichard Purdie2019-06-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This switches the code to build pkgdata specific to the current recipe which means that its filtered to the recipes dependencies and can perform better as we can drop the lockfile. It uses a similar method to the staging code to do this, using BB_TASKDEPDATA to construct a list of packagedata task output which this recipe should "see". The original pkgdata store is left unaltered so existing code works. The lock file was there to prevent files disappearing as they were read or as directories were listed. Since we have a copy of the data and only access output from completed tasks (as per their manifests), we can remove the lock. The lock was causing starvation issues on systems with parallelism. There was also a potential determinism problem as the current code could "see" data from recipes which it doesn't depend upon. [YOCTO #13412] (From OE-Core rev: 1951132576bfb95675b4879287f8b3b7c47524fa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: add python3 supportMaciej Pijanowski2019-06-101-11/+11
| | | | | | | | | | | | | | | | Add support for generating python3 recipes using the recipetool / devtool. Drop python2 support at the same time. Tested with: oe-selftest -r recipetool.RecipetoolTest [YOCTO #13264] (From OE-Core rev: d8b2f58974482b3b1ccc65c5f93104d0d7ba87bc) Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/lib+scripts: Convert to SPDX license headersRichard Purdie2019-05-0910-110/+10
| | | | | | | | | | | | | | | | | | | | | | | This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: fix unbound variable when fixed SRCREV can't be foundAlex Kiernan2019-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | If attempting to find a fixed SRCREV fails because the directory doesn't exit, avoid failing with: Traceback (most recent call last): File "/home/vagrant/poky/scripts/recipetool", line 121, in <module> ret = main() File "/home/vagrant/poky/scripts/recipetool", line 110, in main ret = args.func(args) File "/home/vagrant/poky/scripts/lib/recipetool/create.py", line 707, in create_recipe srcrev = stdout.rstrip() UnboundLocalError: local variable 'stdout' referenced before assignment Fixes: 000480c42797 ("recipetool / devtool: set a fixed SRCREV by default when fetching from git") (From OE-Core rev: 8e4b301573071ea04911b0df6533c25bc4596b93) Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: add missed moduleLei Yang2019-04-121-0/+1
| | | | | | | | | | | | | | When I use recipetool to add a new recipe, it says: [snip] sys.exit(14) NameError: name 'sys' is not defined [snip] (From OE-Core rev: 051e1c27bbf6a5898f2cf13b78dd3d8d1ec31586) Signed-off-by: Lei Yang <Lei.Yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* logging: use warning instead warnChen Qi2018-07-265-15/+15
| | | | | | | | | | | | | | | | 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>
* recipetool: add 'edit' subcommandChristopher Larson2018-07-041-0/+54
| | | | | | | | | | This edits the recipe and any bbappends for the specified target. (From OE-Core rev: 7aece42c6b4744c54a8eb05ff90bd3bf4fbb14a3) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: fixed uncaught NameError exceptionSarah Marsh2018-05-041-0/+1
| | | | | | | | | | | When packaging a node application, a `NameError` can be thrown in create_npm.py if an optional npm dependency does not support Linux. (From OE-Core rev: 8293201d98d368d6322eaa960fb3e7cee2ba9368) Signed-off-by: Sarah Marsh <sarah.marsh@arm.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix port number parsing issueMing Liu2018-04-031-2/+4
| | | | | | | | | | | | | | | | | A flaw was found when I run: $ recipetool create "ssh://git@xxx.xxx:7999/xxx.git" the url turned out to be: "git://git@xxx.xxx/7999/xxx.git;protocol=ssh" after parsing, the port number was parsed as part of the path, this is definitely wrong and lead to fetching failures. This issue could be fixed in reformat_git_uri, by filtering out port numbers when formatting ":". (From OE-Core rev: 4290e04b69360b5e1da9f37166015e30f66cb335) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix conflict between SRCREV and tagChang Rebecca Swee Fun2017-12-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | If you specify 'tag=' for a git URL and passed to recipetool create, you will get into Bitbake expansion error shown below: ----- snip ----- $ devtool add --version 2.4.2 mbedtls "git://github.com/ARMmbed/mbedtls;tag=mbedtls-2.4.2" ... bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Conflicting revisions (abeccb9dbd7e19ae91ac50e1edd3803111c5f9b6 from SRCREV and mbedtls-2.4.2 from the url) found, please specify one valid value ----- snip ----- Assuming the tag is valid, we should get the tag commit hash and drop the usage of 'tag=' from SRC_URI. By using a commit hash corresponding to the tag will prevent bitbake from accessing remote repository in order to expand SRCPV. (From OE-Core rev: 53f8effa3eb07dc7035ff9933e7918318f242579) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix failure handling included dictsPaul Eggleton2017-11-211-0/+2
| | | | | | | | | | | | | | | | | If a setup dict in a python setup.py file pulled in the contents of another dict (e.g. **otherdict), then we got an error when mapping the keys because the key is None in that case. Skip those keys to avoid the error (we pick up the values directly in any case). A quick reproducer for this issue: recipetool create https://files.pythonhosted.org/packages/source/p/pyqtgraph/pyqtgraph-0.10.0.tar.gz (From OE-Core rev: ae62a9953e219df5147ed4a5ae3f4163d51cff28) 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>
* recipetool: create: show a warning for github archive URLsPaul Eggleton2017-11-111-0/+3
| | | | | | | | | | | | | | github archive URLs are not guaranteed to be stable [1] and thus we should show a warning if a user specifies one to recipetool create (or devtool add). [1] http://lists.openembedded.org/pipermail/openembedded-core/2017-September/142519.html (From OE-Core rev: 7e84a777aa924a237b4e604120ebf8a4b3ba53b2) 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>
* recipetool: create: drop debug printPaul Eggleton2017-11-111-1/+0
| | | | | | | | | | This looks like some debug printing that was left in by accident. (From OE-Core rev: b0bfa1b1f4377270af9e7f19949cc1781a4e3b9d) 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>
* recipetool: ignore incidental kernel module sourcePaul Eggleton2017-11-112-3/+5
| | | | | | | | | | | | | | | | | If the source tree happens to contain a kernel module as an example, a test or under a "contrib" directory then we shouldn't be picking it up and making the determination that the entire thing is a kernel module. An example that triggered this is zstd, which ships a kernel module under contrib/linux-kernel: https://github.com/facebook/zstd (From OE-Core rev: c2b3154158d4bb0855daa56477393341139d4cf9) 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>
* recipetool: pass absolute source tree path to pluginsPaul Eggleton2017-11-111-2/+2
| | | | | | | | | | We shouldn't be passing a relative path to the plugins if that's what's been specified on the recipetool command line. (From OE-Core rev: 949067384c5166058ebc76f931cc492dad1db645) 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/+3
| | | | | | | | | | | | | | | | | | | | 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>
* recipetool: create: detect Eclipse licensesPaul Eggleton2017-08-311-1/+5
| | | | | | | | | Add detection of EPL 1.0 and EDL 1.0 license files. (From OE-Core rev: 41e7580991f8ad77a57eb7fd292e39f1583109f6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: suppress npm shrinkwrap/lockdown warnings againPaul Eggleton2017-08-311-0/+2
| | | | | | | | | | | | | | Since OE-Core revision 9a47a6690052ef943c0d4760630ee630fb012153 the mechanism we were using to suppress the warnings about NPM_LOCKDOWN and NPM_SHRINKWRAP not being set on the first fetch of the source is no longer available since we are using the normal fetch/unpack tasks to do the job. Use the newly added noverify parameter to suppress the warnings again. (From OE-Core rev: cb083b6f5f6e909b7c85548bcb1a92ca34d0c18a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix SRCPV prefix for non-git SCMsPaul Eggleton2017-08-311-1/+9
| | | | | | | | | | | If you're fetching from an SCM other than git (for example subversion or mercurial) then we need to use a different prefix for the SRCPV in PV instead of +git. (From OE-Core rev: ad1200c8729f21b325d347649f9dd5e5598de93e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: make recently added branch/tag handling git specificPaul Eggleton2017-08-311-2/+2
| | | | | | | | | | | | The branch and tag handling code that was recently added in OE-Core revs ecca596b75cfda2f798a0bdde75f4f774e23a95b and 3afdcbdc9a3e65bc925ec61717784ffec67d529d is specific to git, so only apply it when we're fetching from a git URL. (From OE-Core rev: 5d4bfe6cf788ce971a2e9419bc13492153023681) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: add explicit srcrev/branch optionsPaul Eggleton2017-08-311-3/+22
| | | | | | | | | | | | | | | | 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>
* recipetool: create: fix npm license code regressionPaul Eggleton2017-08-231-0/+3
| | | | | | | | | | | | | | OE-Core commit 1df60b09f7a60427795ec828c9c7180e4e52f98c caused a regression in npm handling since it still expected to be able to get the results of the license handling, but this no longer happens until after the npm plugin is called. Thus, call the license handling function ourselves here (which will record this as having been handled so it doesn't get done again later). (From OE-Core rev: 3e408aadaea85b6f192b34d37d508cbaf3cd7164) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix broken import in npm modulePaul Eggleton2017-08-231-1/+1
| | | | | | | | | | | With "import oe" in create_npm.py you get "AttributeError: module 'oe' has no attribute 'package'" when it tries to call oe.package.npm_split_package_dirs(). (From OE-Core rev: 1261900aeac725e5712e0180600753a9d4c67e60) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: allow plugins to set LICENSE and LIC_FILES_CHKSUMPaul Eggleton2017-08-232-80/+79
| | | | | | | | | | | | | | | | | | | | | We were being a bit prescriptive in setting LICENSE and LIC_FILES_CHKSUM. We can't always trust what's in the metadata accompanying some source which plugins will almost always be pulling from, however we do want to allow plugins to set the LICENSE and LIC_FILES_CHKSUM values. Merge what we find in our license file scan with what the plugin sends back. Additionally, plugins can now add a "license" item to the handled list in order to inhibit the normal LICENSE / LIC_FILES_CHKSUM handling if they have already taken care of it completely. Thanks to Mark Horn <mark.d.horn@intel.com> for prompting, testing and fixing this patch. (From OE-Core rev: 1df60b09f7a60427795ec828c9c7180e4e52f98c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: allow plugins to set PN / PV more easilyPaul Eggleton2017-08-231-7/+9
| | | | | | | | | | | | | Previously if we were able to auto-determine the name from the URL, that took precedence over any name that might be set in extravalues by a plugin. Some plugins might be able to get a better idea of the name and thus we should move defaulting of the name further down after the plugins have had a chance to set it. (From OE-Core rev: 3bb979c13463705c4db6c59034661c4cd8100756) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: replacing PV in SRCURIStanley Phoong2017-08-231-1/+3
| | | | | | | | | | | | | During recipe creation, it seems that the automation for replacing ${PV} at the SRCURI for tag, (e.g mbed-tls-${PV}) is causing some issue due to PV assuming it's a git source. A fix is implemented in this patch to resolve this issue. (From OE-Core rev: 9d3ec76c1b7dd75d904f5ff47297de0fb65b21c2) Signed-off-by: Stanley Phoong <stanley.cheong.kwan.phoong@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: handle git URLs specifying only a tagStanley Phoong2017-08-231-1/+22
| | | | | | | | | | | | | If a git URL is passed to recipetool create with a tag=, recipetool should handle it assuming that the tag is valid. [YOCTO #11393] (From OE-Core rev: 3afdcbdc9a3e65bc925ec61717784ffec67d529d) Signed-off-by: Stanley Phoong <stanley.cheong.kwan.phoong@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: being able to set branch when revision is providedChang Rebecca Swee Fun2017-08-231-0/+48
| | | | | | | | | | | | | | | | | | | | | This change is to improve the buildability of the recipe created by recipetool and devtool. When recipetool create is run on a git URL and a revision specified that is not on master, and "branch=" isn't already in the URL, then we should get the correct branch and append the branch to the URL. If the revision was found on multiple branches and 'master' is not in the list, we will display error to inform user to provide a correct branch and exit. [YOCTO #11389] (From OE-Core rev: ecca596b75cfda2f798a0bdde75f4f774e23a95b) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: disable PREMIRRORS and MIRRORS by defaultChang Rebecca Swee Fun2017-08-231-0/+1
| | | | | | | | | | | | | | | When creating new recipes, we are almost certainly fetching a new source rather that something that has already been fetched. I have disable PREMIRRORS and MIRRORS settings in the recipe that created by devtool while leaving an option for users to enable them manually if needed. Since devtool already has this options, we need to ensure that recipetool is able to handle the options passed from devtool. (From OE-Core rev: 091cee2bdc2378a3425a4ef8558d03e6f9c021ff) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix incorrect URL variable usagePaul Eggleton2017-08-171-1/+1
| | | | | | | | | | | | | | | | | We have two variables here, srcuri and fetchuri. srcuri is what eventually ends up in the recipe, whereas fetchuri is what we actually pass to the fetcher when we fetch the source within recipetool - sometimes these need to be different particularly for an upcoming patch to handle automatically setting the branch parameter. In OE-Core revision 9a47a6690052ef943c0d4760630ee630fb012153 I erroneously changed the call to scriptutils.fetch_url() to pass srcuri instead of fetchuri - this likely didn't have any ill effect, but change it back to passing fetchuri to match the original intent. (From OE-Core rev: b66b73bcf5ee7e4488970576fdc31dfa25b35f5e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scriptutils: pass in logger as parameterChang Rebecca Swee Fun2017-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | logger was not defined in scriptutils.py based on the observation in python traceback. Traceback (most recent call last): File "/workdir/poky/scripts/devtool", line 351, in <module> ret = main() File "/workdir/poky/scripts/devtool", line 338, in main ret = args.func(args, config, basepath, workspace) File "/workdir/poky/scripts/lib/devtool/utilcmds.py", line 55, in edit_recipe return scriptutils.run_editor(find_recipe(args, config, basepath, workspace)) File "/workdir/poky/scripts/lib/scriptutils.py", line 141, in run_editor logger.error("Execution of '%s' failed: %s" % (editor, exc)) NameError: name 'logger' is not defined We pass in logger as parameter to run_editor() from where it has been called (devtool/utilcmds.py and recipetool/newappend.py), which both modules already has logger setup. (From OE-Core rev: 21f04b61973dd9029f0e6bff5445e31cd762bf32) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: refactor code for ensuring npm is availablePaul Eggleton2017-07-212-22/+26
| | | | | | | | | | | | | | | | | | | Across devtool and recipetool we had an ugly set of code for ensuring that we can call an npm binary, and much of that ugliness was a result of not being able to run build tasks when tinfoil was active - if recipetool found that npm was required and we didn't know beforehand (e.g. we're fetching from a plain git repository as opposed to an npm:// URL where it's obvious) then it had to exit and return a special result code, so that devtool knew it needed to build nodejs-native and then call recipetool again. Now that we are using real build tasks to fetch and unpack, we can drop most of this and move the code to the one place where it's still needed (i.e. create_npm where we potentially have to deal with node.js code in a plain source repository). (From OE-Core rev: 8450de16ddb02d863204b411a94c6d84e0f88817) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: reimplement fetching with normal fetch/unpack tasksPaul Eggleton2017-07-212-25/+25
| | | | | | | | | | | | | | | | | | | | Now that we have the ability to run the tasks in a more standard context through tinfoil, change recipetool's fetching code to use that to fetch files using it. This has the major advantage that any dependencies of do_fetch and do_unpack (e.g. for subversion or npm) will be handled automatically. This also has the beneficial side-effect of fixing a recent regression that prevented this fetch operation from working with memory resident bitbake. Also fix devtool's usage of fetch_uri() at the same time so that we can completely replace it. Fixes [YOCTO #11710]. (From OE-Core rev: 9a47a6690052ef943c0d4760630ee630fb012153) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: eliminate second fetch for packagesPaul Eggleton2017-07-211-15/+6
| | | | | | | | | | | | | When dealing with package files (.rpm, .ipk etc.) we need to unpack them ourselves to get the metadata, which is thrown away when the fetcher unpacks them. However, since we've already fetched the file once, I'm not sure as to why I thought I needed to fetch it again - we can just get the local path and then unpack it directly. (From OE-Core rev: be45e9b17e9dbc8c2594d3a939be377ab0720a7c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: ensure meaningful error for malformed tarballsPaul Eggleton2017-07-211-4/+18
| | | | | | | | | | | | | | | | | | | If you pointed recipetool at a URL that should be a tarball e.g. https://tls.mbed.org/download/start/mbedtls-2.4.2-apache.tgz but instead it returns an HTML page, we try to unpack it, gzip complains but the operation doesn't seem to fail - instead we just get back an empty source tree. Change the checks to account for this - if the source tree is empty, check if the downloaded file in DL_DIR looks like an HTML file and error accordingly if it is. If it's not, error out anyway because no source was unpacked and it should have been (otherwise we just blindly set up EXTERNALSRC for this which is pointless). Fixes an aspect of [YOCTO #11407]. (From OE-Core rev: 8496113b63d5a5d1f99056610c0fdb972a6200d4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: git reformat URI mangling & parameter strippedStanley Cheong Kwan, Phoong2017-07-171-9/+26
| | | | | | | | | | | | | | | | recipetool seems to be mangling and stripping out the parameters for git URI. This will fix this issue as well as resolve the conflict of protocol parameter added by user. If a user adds their own protocol as an argument, it'll be honored. [YOCTO #11390] [YOCTO #11391] (From OE-Core rev: 0cd2fc8ca278ebaa76de95545eef26a07b350c8e) Signed-off-by: Stanley Cheong Kwan, Phoong <stanley.cheong.kwan.phoong@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: extract name of package from a repositoryPaul Eggleton2017-05-231-3/+8
| | | | | | | | | | | | | For git repositories in the absence of any other indicator, it's not an unreasonable assumption that the name of the repository is the name of the software package it contains, so use that as PN if we don't have anything else. (From OE-Core rev: ef73fa70f0955912b0da140922465a3c817424e9) 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>
* recipetool: create: skip values extracted from spec files containing macrosPaul Eggleton2017-05-231-0/+4
| | | | | | | | | | | | | | | | | | If a value we extract from a spec file contains an unexpanded macro (e.g. %{macroname}) then we should discard it since we're not seeing the actual value and we don't have an easy way of expanding it at the moment. This fixes for example getting %{name} as the recipe name when running the following: recipetool create https://github.com/gavincarr/mod_auth_tkt.git (From OE-Core rev: eee56a19cda051da6267f808cd3a04a4c644acb3) 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>
* recipetool: create: hide missing npm error when called from devtoolPaul Eggleton2017-04-132-1/+5
| | | | | | | | | | | | | | | | | If devtool is called with a URL to a source repository containing a node.js module, we don't know that until recipetool has fetched it, and due to the structure of the code we have to exit with a special code in order to let devtool know it needs to build nodejs-native. We also want to suppress the error message that recipetool would normally print under these circumstances; there is already a mechanism for this but it wasn't operative in the case where we're pointed to a source repository rather than an npm:// URL, so create some plumbing so that we know to hide the message. (From OE-Core rev: 0c2d0fbb1c6c5b82183799eb7ef80074f86bcfc4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: fix node.js/npm handling with recipe specific sysrootsPaul Eggleton2017-04-132-15/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change over to recipe specific sysroots means that we can no longer get a known location simply from configuration for the npm binary - we need to get the recipe sysroot for nodejs-native, look there for npm if we need to check it's present, and add that to PATH when calling out to npm. Unfortunately this means anywhere we need to get that path we have to have parsed all recipes, otherwise we have no reliable way of resolving nodejs-native. Thus we have to change recipetool create to always parse all recipes (the structure of the code does not allow us to do this conditionally). In the worst case, if npm hasn't already been added to its own sysroot and we are fetching from a source repository rather than an npm registry, this gets a bit ugly because we end up parsing recipes three times: 1) recipetool startup, which then fetches the code and determines it's a node.js module, finds that npm isn't available and then exits with a specific error to tell devtool it needs to build npm 2) when we invoke bitbake -c addto_recipe_sysroot nodejs-native 3) when we re-invoke recipetool This code is badly in need of refactoring, but now is unfortunately not the time to do that, so we're going to have to live with this ugliness for now. Fixes [YOCTO #10992]. (From OE-Core rev: acfdbd796c99882b8586023c8c6b848716105c8d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: fix for regression in npm license handlingPaul Eggleton2017-04-131-1/+2
| | | | | | | | | | | | OE-Core commit c0cfd9b1d54b05ad048f444d6fe248aa0500159e added handling for AND / OR in license strings coming from npm, but made the assumption that an & would always be present in the license value. Check if it's there first so we don't fail if it isn't. (From OE-Core rev: abe2955df2dc558de6068d9373dfcb47d690704b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/recipetill: npm install of devDependenciesAnders Darander2017-03-222-5/+24
| | | | | | | | | | | | | | Web applications built using e.g. angular2, usually requires that the packages in devDependencies are available. Thus, add an option '--fetch-dev' to both devtool add and recipetool, to add npm packages in devDependencies to DEPENDS. (From OE-Core rev: f246f820d53b459596fde6758a09f7a0d7db7c4c) Signed-off-by: Anders Darander <anders@chargestorm.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/lib/create_npm: handle Public Domain licensesAnders Darander2017-03-041-0/+1
| | | | | | | | | | | Rewrite Public Domain as PD, as that's what the place holder in meta/files/common_licenses is called. (From OE-Core rev: d7f0af5aa90a9ef7714c842fb4cb762017820768) Signed-off-by: Anders Darander <anders@chargestorm.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/lib/create_npm: handle AND and OR in licensesAnders Darander2017-03-041-1/+15
| | | | | | | | | | | | Handle npm packages with multiple licenses (AND and OR). Prior to this, AND and OR were treated as licensed in their own. (From OE-Core rev: c0cfd9b1d54b05ad048f444d6fe248aa0500159e) Signed-off-by: Anders Darander <anders@chargestorm.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/lib/create_npm: rewrite see license in eulaAnders Darander2017-03-041-2/+4
| | | | | | | | | | | | | | Rewrite the 'SEE LICENSE IN EULA' to a single string (without spaces), to avoid splitting the string later on. (Otherwise, each word gets split, and assumed to be a license on it's own. (From OE-Core rev: 39127702cee80c972ee9a447ef4006751f47475e) Signed-off-by: Anders Darander <anders@chargestorm.se> Signed-off-by: Ross Burton <ross.burton@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-11-17 02:24:57 +0000