migrate to go-modules

Signed-off-by: Valentin Rothberg <rothberg@redhat.com>

4 files changed, 148 insertions, 0 deletions

diff --git a/vendor/github.com/seccomp/libseccomp-golang/.gitignore b/vendor/github.com/seccomp/libseccomp-golang/.gitignore
new file mode 100644
index 000000000..b4826968b
--- /dev/null
+++ b/vendor/github.com/seccomp/libseccomp-golang/.gitignore
@@ -0,0 +1,4 @@
+*~
+*.swp
+*.orig
+tags
diff --git a/vendor/github.com/seccomp/libseccomp-golang/CHANGELOG b/vendor/github.com/seccomp/libseccomp-golang/CHANGELOG
new file mode 100644
index 000000000..823aeb7f8
--- /dev/null
+++ b/vendor/github.com/seccomp/libseccomp-golang/CHANGELOG
@@ -0,0 +1,6 @@
+libseccomp-golang: Releases
+===============================================================================
+https://github.com/seccomp/libseccomp-golang
+
+* Version 0.9.0 - January 5, 2017
+- Initial tagged release
diff --git a/vendor/github.com/seccomp/libseccomp-golang/Makefile b/vendor/github.com/seccomp/libseccomp-golang/Makefile
new file mode 100644
index 000000000..1ff4cc898
--- /dev/null
+++ b/vendor/github.com/seccomp/libseccomp-golang/Makefile
@@ -0,0 +1,26 @@
+# libseccomp-golang
+
+.PHONY: all check check-build check-syntax fix-syntax vet test lint
+
+all: check-build
+
+check: vet test
+
+check-build:
+	go build
+
+check-syntax:
+	gofmt -d .
+
+fix-syntax:
+	gofmt -w .
+
+vet:
+	go vet -v
+
+test:
+	go test -v
+
+lint:
+	@$(if $(shell which golint),true,$(error "install golint and include it in your PATH"))
+	golint -set_exit_status
diff --git a/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES b/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES
new file mode 100644
index 000000000..744e5cd64
--- /dev/null
+++ b/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES
@@ -0,0 +1,112 @@
+How to Submit Patches to the libseccomp Project
+===============================================================================
+https://github.com/seccomp/libseccomp-golang
+
+This document is intended to act as a guide to help you contribute to the
+libseccomp project.  It is not perfect, and there will always be exceptions
+to the rules described here, but by following the instructions below you
+should have a much easier time getting your work merged with the upstream
+project.
+
+* Test Your Code
+
+There are two possible tests you can run to verify your code.  The first test
+is used to check the formatting and coding style of your changes, you can run
+the test with the following command:
+
+	# make check-syntax
+
+... if there are any problems with your changes a diff/patch will be shown
+which indicates the problems and how to fix them.
+
+The second possible test is used to ensure the sanity of your code changes
+and to test these changes against the included tests.  You can run the test
+with the following command:
+
+	# make check
+
+... if there are any faults or errors they will be displayed.
+
+* Generate the Patch(es)
+
+Depending on how you decided to work with the libseccomp code base and what
+tools you are using there are different ways to generate your patch(es).
+However, regardless of what tools you use, you should always generate your
+patches using the "unified" diff/patch format and the patches should always
+apply to the libseccomp source tree using the following command from the top
+directory of the libseccomp sources:
+
+	# patch -p1 < changes.patch
+
+If you are not using git, stacked git (stgit), or some other tool which can
+generate patch files for you automatically, you may find the following command
+helpful in generating patches, where "libseccomp.orig/" is the unmodified
+source code directory and "libseccomp/" is the source code directory with your
+changes:
+
+	# diff -purN libseccomp-golang.orig/ libseccomp-golang/
+
+When in doubt please generate your patch and try applying it to an unmodified
+copy of the libseccomp sources; if it fails for you, it will fail for the rest
+of us.
+
+* Explain Your Work
+
+At the top of every patch you should include a description of the problem you
+are trying to solve, how you solved it, and why you chose the solution you
+implemented.  If you are submitting a bug fix, it is also incredibly helpful
+if you can describe/include a reproducer for the problem in the description as
+well as instructions on how to test for the bug and verify that it has been
+fixed.
+
+* Sign Your Work
+
+The sign-off is a simple line at the end of the patch description, which
+certifies that you wrote it or otherwise have the right to pass it on as an
+open-source patch.  The "Developer's Certificate of Origin" pledge is taken
+from the Linux Kernel and the rules are pretty simple:
+
+	Developer's Certificate of Origin 1.1
+
+	By making a contribution to this project, I certify that:
+
+	(a) The contribution was created in whole or in part by me and I
+	    have the right to submit it under the open source license
+	    indicated in the file; or
+
+	(b) The contribution is based upon previous work that, to the best
+	    of my knowledge, is covered under an appropriate open source
+	    license and I have the right under that license to submit that
+	    work with modifications, whether created in whole or in part
+	    by me, under the same open source license (unless I am
+	    permitted to submit under a different license), as indicated
+	    in the file; or
+
+	(c) The contribution was provided directly to me by some other
+	    person who certified (a), (b) or (c) and I have not modified
+	    it.
+
+	(d) I understand and agree that this project and the contribution
+	    are public and that a record of the contribution (including all
+	    personal information I submit with it, including my sign-off) is
+	    maintained indefinitely and may be redistributed consistent with
+	    this project or the open source license(s) involved.
+
+... then you just add a line to the bottom of your patch description, with
+your real name, saying:
+
+	Signed-off-by: Random J Developer <random@developer.example.org>
+
+* Email Your Patch(es)
+
+Finally, you will need to email your patches to the mailing list so they can
+be reviewed and potentially merged into the main libseccomp-golang repository.
+When sending patches to the mailing list it is important to send your email in
+text form, no HTML mail please, and ensure that your email client does not
+mangle your patches.  It should be possible to save your raw email to disk and
+apply it directly to the libseccomp source code; if that fails then you likely
+have a problem with your email client.  When in doubt try a test first by
+sending yourself an email with your patch and attempting to apply the emailed
+patch to the libseccomp-golang repository; if it fails for you, it will fail
+for the rest of us trying to test your patch and include it in the main
+libseccomp-golang repository.