Removing Suricata and Audit from source repo, and updated build.sh to avoid building suricata. Will re-address this in C release via tar balls.

Change-Id: I3710076f8b7f3313cb3cb5260c4eb0a6834d4f6e
Signed-off-by: Ashlee Young <ashlee@wildernessvoice.com>

1 files changed, 0 insertions, 90 deletions

diff --git a/framework/src/suricata/doc/GITGUIDE b/framework/src/suricata/doc/GITGUIDE
deleted file mode 100644
index 41b4059a..00000000
--- a/framework/src/suricata/doc/GITGUIDE
+++ /dev/null
@@ -1,90 +0,0 @@
-Guide for using GIT
-
-Working with Git is significantly different that working with SVN. In particular, although similar, git pull is not svn update, git push is not svn commit, and git add is not svn add. If you are a SVN user, be sure to read the man pages for the different git commands.
-
-The following workflow is recommended by Evan and is the guideline for contributing code to Rubinius.
-
-   1.
-
-      Create a local working copy of the source code (we did this earlier.)
-
-      # See above for the exact invocation
-
-   2.
-
-      Change to the newly created directory that contains the local working copy. (Substitute the directory if you created it with a different name, obviously.)
-
-      cd code
-
-   3.
-
-      Create a branch for your work. This will make a copy of the current branch (master) and name it "new_feature". Now you can work in this new branch without breaking the main one.
-
-      git checkout -b new_feature
-
-   4.
-
-      Edit the code and test your changes. Then commit to your local working copy
-
-      git commit -a
-
-   5.
-
-      When you are ready to send your local changes back to the Rubinius repository, you first need to ensure that your local copy is up-to-date. First, ensure you have committed your local changes. Then switch from your topic branch to the master branch.
-
-      git checkout master
-
-   6.
-
-      Update your local copy with changes from the Rubinius repository
-
-      git pull
-
-   7.
-
-      Switch back to your topic branch and integrate any new changes. The git rebase command will save your changes away, update the topic branch, and then reapply them.
-
-      git checkout new_feature
-      git rebase master
-
-      Warning! If you are sharing a branch, you must use:
-
-      git merge master
-
-      Rebase causes the commit layout to change and will confuse anyone you've shared this branch with.
-
-   8.
-
-      If there are conflicts applying your changes during the git rebase command, fix them and use the following to finish applying them
-
-      git rebase --continue
-
-   9.
-
-      Now, switch back to the master branch and merge your changes from the topic branch
-
-      git checkout master
-      git merge new_feature
-
-  10.
-
-      You might want to check that your commits ended up as you intended. To do so, you can have a look at the log
-
-      git log
-
-  11.
-
-      Get your changes in the main repository. If you have commit rights, you can just use the git push command. Otherwise, see the section below for information on creating a set of patches to send.
-
-      git push
-
-  12.
-
-      At this point, you can delete the branch if you like.
-
-      git branch -d new_feature
-
-When you're familiar with the workflow, you can use the rake tasks to help you out. For example, rake git will fetch the latest code from remote repo, rebase the current branch to master, fast-forward the changes to master and push the commits to the remote. This saves a lot of typing. Check rake -T git for all the git related tasks.
-
-Taken from: http://rubinius.lighthouseapp.com/projects/5089/using-git
-