Switch to containers/common for seccomp

The seccomp/containers-golang library is not maintained any more and we
should stick to containers/common.

Signed-off-by: Sascha Grunert <sgrunert@suse.com>

1 files changed, 0 insertions, 112 deletions

diff --git a/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES b/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES
deleted file mode 100644
index 744e5cd64..000000000
--- a/vendor/github.com/seccomp/libseccomp-golang/SUBMITTING_PATCHES
+++ /dev/null
@@ -1,112 +0,0 @@
-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.