adding missing sections and update to version 2.6.0

_build/html/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: fbaa1bf6d218224192d49424b07b5281
+config: 016ec39474a3005cc1c532a195a0e7a9
 tags: 645f666f9bcd5a90fca523b33c5a78b7

_build/html/_sources/appendix.rst.txt

@@ -94,6 +94,7 @@ from the same starting point. For example, you may want to build several contain
 compiler toolchain, or the same base MPI installation. Instead of building these from scratch each time, you could create a base container on
 Singularity Hub and then build new containers from that existing base container adding customizations in ``%post`` , ``%environment``, ``%runscript``, etc.
 
+
 Keywords
 ========
 

_build/html/_sources/bind_paths_and_mounts.rst.txt

@@ -23,6 +23,7 @@ container. To enable this functionality, Singularity will bind
 directories back in via two primary methods: system-defined bind points
 and conditional user-defined bind points.
 
+
 System-defined bind points
 ==========================
 

_build/html/_sources/build_a_container.rst.txt

@@ -90,9 +90,9 @@ Singularity containers.
 
     $ singularity build lolcow.simg docker://godlovedc/lolcow
 
-------------------------------------------------------
+------------------------------------------------------------
 Creating ``--writable`` images and ``--sandbox`` directories
-------------------------------------------------------
+------------------------------------------------------------
 
 ``--writable``
 ==============
@@ -258,8 +258,7 @@ container, you could re-build only the ``%environment`` section like so:
 
 Under normal build conditions, the Singularity recipe file is saved into
 a container’s meta-data so that there is a record showing how the
-container was built. Using the ``--section`` option may render this meta-data useless,
-so use care if you value reproducibility.
+container was built. Using the ``--section`` option may render this meta-data useless, so use care if you value reproducibility.
 
 ``--notest``
 ============

_build/html/_sources/build_environment.rst.txt

@@ -215,8 +215,7 @@ General
 **SINGULARITY_PYTHREADS** The Python modules use threads (workers) to
 download layer files for Docker, and change permissions. By default,
 we will use 9 workers, unless the environment variable ``SINGULARITY_PYTHREADS`` is defined.
-**SINGULARITY_COMMAND_ASIS** By default, we want to make sure the
-container running process gets passed forward as the current process,
+**SINGULARITY_COMMAND_ASIS** By default, we want to make sure the container running process gets passed forward as the current process,
 so we want to prefix whatever the Docker command or entrypoint is with
 ``exec``. We also want to make sure that following arguments get passed, so we
 append ``"$@"``. Thus, some entrypoint or cmd might look like this:

_build/html/_sources/container_checks.rst.txt

@@ -4,8 +4,7 @@ Container Checks
 
 New to Singularity 2.4 is the ability to run container “checks” on
 demand. Checks can be anything from a filter for sensitive
-information, to an analysis of installed binaries. A few default
-checks are installed with Singularity and others can be added by the
+information, to an analysis of installed binaries. A few default checks are installed with Singularity and others can be added by the
 administrator. Users can perform checks at build time or on demand:
 Perform all default checks, these are the same
 

_build/html/_sources/container_recipes.rst.txt

@@ -9,8 +9,7 @@ Container Recipes
 
 A Singularity Recipe is the driver of a custom build, and the starting
 point for designing any custom container. It includes specifics about
-installation software, environment variables, files to add, and
-container metadata. You can even write a help section, or define modular
+installation software, environment variables, files to add, and container metadata. You can even write a help section, or define modular
 components in the container called based on the `Scientific
 Filesystem <https://sci-f.github.io/>`_.
 

_build/html/_sources/contributing.rst.txt

@@ -0,0 +1,283 @@
+============
+Contributing
+============
+
+-------------------
+Support Singularity
+-------------------
+
+Singularity is an open source project, meaning we have the challenge of limited resources.
+We are grateful for any support that you might offer to other users in the way of helping with issues, documentation,
+or code! If you haven’t already, check out some of the ways to contribute to code and docs:
+
+-  contribute code
+
+-  contribute docs
+
+Singularity Google Group
+========================
+
+This is a huge endeavor, and it is greatly appreciated! If you have been using Singularity and having good luck with it,
+join our `Google Group <https://groups.google.com/a/lbl.gov/forum/#!forum/singularity>`_  and help out other users! Post to online communities about Singularity, and request that your distribution vendor,
+service provider, and system administrators include Singularity for you!
+
+Singularity on Slack
+====================
+
+Many of our users come to slack for quick help with an issue. You can find us at `singularity-container <https://singularity-container.slack.com/>`_.
+
+
+----------------------
+Contribute to the code
+----------------------
+
+To contribute to the development of Singularity, you must:
+
+-  Own the code and/or have the right to contribute it
+
+-  Be able to submit software under the 3 clause BSD (or equivalent) license (while other licenses are allowed to be submitted by the license, acceptance of any contribution is up to the project lead)
+
+-  Read, understand and agree to the license
+
+-  Have a GitHub account (this just makes it easier on me)
+
+We use the traditional `GitHub Flow <https://guides.github.com/introduction/flow/>`_ to develop. This means that you fork the repo and checkout a branch to make changes, you submit a pull request (PR) to the development branch with your changes, and the development branch gets merged with master for official releases.
+We also have an official `CONTRIBUTING <https://github.com/singularityware/singularity/blob/master/CONTRIBUTING.md>`_ document, which also includes a `code of conduct <https://github.com/singularityware/singularity/blob/master/CONTRIBUTING.md#code-of-conduct>`_  .
+
+
+Step 1. Fork the repo
+=====================
+
+To contribute to the web based documentation, you should obtain a GitHub account and fork the `Singularity <https://github.com/singularityware/singularity>`_ repository.
+Once forked, you will want to clone the fork of the repo to your computer. Let’s say my GitHub username is vsoch, and I am using ssh:
+
+.. code-block:: none
+
+    git clone [email protected]:vsoch/singularity.git
+
+    cd singularity/
+
+
+Step 2. Set up your config
+==========================
+
+The GitHub config file, located at .git/config, is the best way to keep track of many different forks of a repository.
+I usually open it up right after cloning my fork to add the repository that I forked as a `remote <https://help.github.com/articles/adding-a-remote/>`_, so I can easily get updated from it.
+Let’s say my ``.git/config`` first looks like this, after I clone my own branch:
+
+.. code-block:: none
+
+    [core]
+
+        repositoryformatversion = 0
+
+        filemode = true
+
+        bare = false
+
+        logallrefupdates = true
+
+    [remote "origin"]
+
+        url = [email protected]:vsoch/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [branch "master"]
+
+        remote = origin
+
+        merge = refs/heads/master
+
+
+I would want to add the upstream repository, which is where I forked from.
+
+.. code-block:: none
+
+    [core]
+
+        repositoryformatversion = 0
+
+        filemode = true
+
+        bare = false
+
+        logallrefupdates = true
+
+    [remote "origin"]
+
+        url = [email protected]:vsoch/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [remote "upstream"]
+
+        url = https://github.com/singularityware/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [branch "master"]
+
+        remote = origin
+
+        merge = refs/heads/master
+
+
+I can also add some of my colleagues, if I want to pull from their branches:
+
+.. code-block:: none
+
+    [core]
+
+        repositoryformatversion = 0
+
+        filemode = true
+
+        bare = false
+
+        logallrefupdates = true
+
+    [remote "origin"]
+
+        url = [email protected]:vsoch/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [remote "upstream"]
+
+        url = https://github.com/singularityware/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [remote "greg"]
+
+        url = https://github.com/gmkurtzer/singularity
+
+        fetch = +refs/heads/*:refs/remotes/origin/*
+
+    [branch "master"]
+
+        remote = origin
+
+        merge = refs/heads/master
+
+
+In the GitHub flow, the master branch is the frozen, current version of the software.
+Your master branch is always in sync with the upstream (our singularityware master), and the singularityware master is always the latest release of
+
+This would mean that I can update my master branch as follows:
+
+.. code-block:: none
+
+    git checkout master
+
+    git pull upstream master
+
+    git push origin master
+
+
+and then I would return to working on the branch for my feature. How to do that exactly? Read on!
+
+Step 3. Checkout a new branch
+=============================
+
+`Branches <https://guides.github.com/introduction/flow//>`_ are a way of isolating your features. For example, if I am working on several features, I would want to keep them separate, and “submit them” (in what is called a `pull request <https://help.github.com/articles/about-pull-requests/>`_ ) to be added to the main repository codebase. Each repository, including your fork, has a main branch, which is usually called “master”. As mentioned earlier, the master branch of a fork should always be in sync with the repository it is forked from (which I usually refer to as “upstream”) and then branches of the fork consistently updated with that master. Given that we’ve just cloned the repo, we probably want to work off of the current development branch, which has the most up to date “next version” of the software. So we can start by checking out that branch:
+
+.. code-block:: none
+
+    git checkout -b development
+
+    git pull origin development
+
+
+At this point, you can either choose to work on this branch, push to your origin development and pull request to singularityware development, or you can checkout another branch specific to your feature. We recommend always working from, and staying in sync with development. The command below would checkout a branch called ``add/my-awesome-new-feature`` from development.
+
+.. code-block:: none
+
+    # Checkout a new branch called add/my-awesome-feature
+
+    git checkout -b add/my-awesome-feature development
+
+
+The addition of the ``-b`` argument tells git that we want to make a new branch. If I want to just change branches (for example back to master) I can do the same command without ``-b``:
+
+.. code-block:: none
+
+    # Change back to master
+
+    git checkout master
+
+
+Note that you should commit changes to the branch you are working on before changing branches, otherwise they would be lost. GitHub will give you a warning and prevent you from changing branches if this is the case, so don’t worry too much about it.
+
+
+Step 4. Make your changes
+=========================
+
+On your new branch, go nuts! Make changes, test them, and when you are happy with a bit of progress, commit the changes to the branch:
+
+.. code-block:: none
+
+    git commit -a
+
+
+This will open up a little window in your default text editor that you can write a message in the first line. This commit message is important - it should describe exactly the changes that you have made. Bad commit messages are like:
+
+- changed code
+
+- updated files
+
+Good commit messages are like:
+
+- changed function “get_config” in functions.py to output csv to fix #2
+
+- updated docs about shell to close #10
+
+The tags “close #10” and “fix #2” are referencing issues that are posted on the main repo you are going to do a pull request to. Given that your fix is merged into the master branch, these messages will automatically close the issues, and further, it will link your commits directly to the issues they intended to fix. This is very important down the line if someone wants to understand your contribution, or (hopefully not) revert the code back to a previous version.
+
+Step 5. Push your branch to your fork
+=====================================
+
+When you are done with your commits, you should push your branch to your fork (and you can also continuously push commits here as you work):
+
+.. code-block:: none
+
+    git push origin add/my-awesome-feature
+
+
+Note that you should always check the status of your branches to see what has been pushed (or not):
+
+.. code-block:: none
+
+    git status
+
+
+Step 6. Submit a Pull Request
+=============================
+
+Once you have pushed your branch, then you can go to either fork and (in the GUI) `submit a Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_. Regardless of the name of your branch, your PR should be submit to the singularityware development branch. This will open up a nice conversation interface / forum for the developers of Singularity to discuss your contribution, likely after testing. At this time, any continuous integration that is linked with the code base will also be run. If there is an issue, you can continue to push commits to your branch and it will update the Pull Request.
+
+Support, helping and spreading the word!
+========================================
+
+This is a huge endeavor, and it is greatly appreciated! If you have been using Singularity and having good luck with it, join our `Google Group <https://groups.google.com/a/lbl.gov/forum/#!forum/singularity>`_ and help out other users! Post to online communities about Singularity, and request that your distribution vendor, service provider, and system administrators include Singularity for you!
+
+-----------------------------
+Contributing to Documentation
+-----------------------------
+
+We (like almost all open source software providers) have a documentation dilemma… We tend to focus on the code features and functionality before working on documentation. And there is very good reason for this, we want to share the love so nobody feels left out!
+
+You can contribute to the documentation, by sending a `pull request <https://help.github.com/articles/about-pull-requests/>`_ on our repository for documentation.
+
+The current documentation is generated with:
+
+- `reStructured Text (RST) <http://docutils.sourceforge.net/rst.html>`_ and `ReadTheDocs <https://readthedocs.org/>`_
+
+Other dependencies include:
+
+- `Python 2.7 <https://www.python.org/download/releases/2.7/>`_
+
+- `Sphinx <https://pypi.org/project/Sphinx/>`_
+
+More information about contributing to the documentation and the instructions on how to install the dependencies and how to generate the files can be obtained `here <https://github.com/singularityware/singularity-userdocs#singularity-user-docs>`_.

_build/html/_sources/environment_and_metadata.rst.txt

@@ -8,8 +8,7 @@ Environment and Metadata
 
 Singularity containers support environment variables and labels that you
 can add to your container during the build process. This page details
-general information about defining environments and labels. If you are
-looking for specific environment variables for build time, see build
+general information about defining environments and labels. If you are looking for specific environment variables for build time, see build
 environment.
 
 -----------