summaryrefslogtreecommitdiff
path: root/scripts/oe-publish-sdk
AgeCommit message (Collapse)AuthorFiles
2016-06-02scripts: python3: change python to python3 in shebangEd Bartosh1
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-18devtool: sdk-update: reset git metadata on updateStephano Cetola1
Replace git pull with fetch and reset to avoid the merge logic in the event that the layers repo in the published SDK we're updating to isn't fast-forward merge from the local repo. Also add gitignore and committer info during publish to avoid errors and to be sure that the first commit has a dummy user in it. [ YOCTO #9368 ] Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-03-31oe-publish-sdk: exclude sstate-cache if publishing minimal SDKPaul Eggleton1
If SDK_EXT_TYPE is set to "minimal" then the SDK won't contain many sstate artifacts, and you're required to set up an sstate mirror in this case anyway so there's no point publishing the "stub" sstate-cache directory from within the SDK since it won't be useful for update purposes and may be confused with the real sstate-cache. There is however a possibility that people might publish the real sstate-cache directory under the same output directory provided to oe-publish-sdk, thus deleting it after extracting (as we were doing with other files we wanted to clean up at the end) would be problematic, besides which extracting it and then deleting it is wasteful. Thus, introduce a "-p" command line option to the SDK installer that we can use to tell tar not to extract the items we don't want when publishing. This has the added benefit of mostly keeping references to these in the place they belong i.e. in populate_sdk_ext.bbclass. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-31oe-publish-sdk: prevent specifying a directory for the SDK argumentPaul Eggleton1
The SDK argument is expected to be an installer .sh file; if a directory is specified we can get an ugly failure later on; best to check up front. Fixes [YOCTO #9065]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-31scripts, lib: Don't limit traceback lengths to arbitrary valuesRichard Purdie1
There appears to have been a lot of copy and pasting of the code which prints tracebacks upon failure and limits the stack trace to 5 entries. This obscures the real error and is very confusing to the user it look me an age to work out why some tracebacks weren't useful. This patch removes the limit, making tracebacks much more useful for debugging. [YOCTO #9230] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-23oe-publish-sdk: fix remote publishingPaul Eggleton1
A typo in the command prevented the last part of the publish from succeeding. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-23oe-publish-sdk: improve help output slightlyPaul Eggleton1
This was just copy-and-pasted from devtool - set a reasonable description and tweak the sdk parameter help text. Also add a copyright statement and drop the opening comment describing the command-line syntax that duplicated the help output (with at least one mistake in it). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-23oe-publish-sdk: drop SDK installer file from published outputPaul Eggleton1
We don't really need the SDK installer in the published output, for two reasons: 1) The directory produced is for the consumption of devtool sdk-update, and the installer isn't used by that at all 2) It wouldn't really make sense to point users at the update directory to download the SDK installer because it contains a bunch of things that aren't meant for manual download, so it wouldn't be very tidy. Leaving the file present can mislead you into thinking the opposite of both of the above. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-11scripts/oe-publish-sdk: add missing call to git update-server-infoPaul Eggleton1
We need to call git update-server-info here on the created repository or we can't share it over plain http as we need to be able to for the update process to function as currently implemented. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22scripts: print usage in argparse-using scripts when a command-line error occursPaul Eggleton1
For scripts that use Python's standard argparse module to parse command-line arguments, create a subclass which will show the usage the usage information when a command-line parsing error occurs. The most common case would be when the script is run with no arguments; at least then the user immediately gets to see what arguments they might need to pass instead of just an error message. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-10-24scripts/oe-publish-sdk: create directory before making git repoCostin Constantin1
This patch fixes a small bug that prevents seting a git repo in exported SDK layers dir. Before setting a git repo, that directory needs to be created. [ YOCTO #6659 ] Signed-off-by: Costin Constantin <costin.c.constantin@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-09-07oe-publish-sdk: add scriptQi.Chen@windriver.com1
Add a script to publish an extensible SDK that has previously been built to a specified destination. This published SDK is intended to be accessed by the devtool sdk-update command from an installed copy of the extensible SDK. e.g. oe-publish-sdk <ext-sdk> <destination> Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>