pulled descriptions from registry.hub

Author: yosifkit

buildpack-deps/README-content.md

@@ -0,0 +1 @@
+

buildpack-deps/README-short.txt

@@ -0,0 +1 @@
+A collection of common build dependencies, especially useful for installing arbitrary modules such as gems where build dependencies can't easily be determined beforehand.

buildpack-deps/README.md

@@ -0,0 +1,27 @@
+
+
+# Issues and Contributing
+
+We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+
+If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
+
+Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
+
+## Conventions
+
+Fork the repository and make changes on your fork in a feature branch.
+
+Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+
+Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+
+Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
+
+Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
+
+Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
+
+Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

gcc/README-content.md

@@ -0,0 +1 @@
+

gcc/README-short.txt

@@ -0,0 +1 @@
+

gcc/README.md

@@ -0,0 +1,27 @@
+
+
+# Issues and Contributing
+
+We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+
+If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/gcc/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
+
+Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
+
+## Conventions
+
+Fork the repository and make changes on your fork in a feature branch.
+
+Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+
+Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+
+Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
+
+Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
+
+Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
+
+Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

golang/README-content.md

@@ -0,0 +1 @@
+

golang/README-short.txt

@@ -0,0 +1 @@
+

golang/README.md

@@ -0,0 +1,27 @@
+
+
+# Issues and Contributing
+
+We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+
+If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/golang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
+
+Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
+
+## Conventions
+
+Fork the repository and make changes on your fork in a feature branch.
+
+Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+
+Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+
+Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
+
+Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
+
+Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
+
+Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.

hello-world/README-content.md

@@ -0,0 +1,22 @@
+$ docker run hello-world
+    Hello from Docker.
+    This message shows that your installation appears to be working correctly.
+    
+    To generate this message, Docker took the following steps:
+     1. The Docker client contacted the Docker daemon.
+     2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
+        (Assuming it was not already locally available.)
+     3. The Docker daemon created a new container from that image which runs the
+        executable that produces the output you are currently reading.
+     4. The Docker daemon streamed that output to the Docker client, which sent it
+        to your terminal.
+    
+    To try something more ambitious, you can run an Ubuntu container with:
+     $ docker run -it ubuntu bash
+    
+    For more examples and ideas, visit:
+     http://docs.docker.com/userguide/
+
+    $ docker images hello-world
+    REPOSITORY      TAG             IMAGE ID        CREATED         VIRTUAL SIZE
+    hello-world     latest          565a9d68a73f    26 hours ago    922 B