Compat with new sphinx

Changed a lot of code:: to code-block::
Also added sphinx_rtd_theme to deps in tox

README.rst

@@ -62,7 +62,7 @@ Here are a few quickstart tutorials for the most common images.
 If you plan on partitioning your volume, you will need the ``parted``
 package and ``kpartx``:
 
-.. code:: sh
+.. code-block:: sh
 
     root@host:~# apt-get install parted kpartx
 
@@ -75,7 +75,7 @@ quits the process.
 Docker
 ~~~~~~
 
-.. code:: sh
+.. code-block:: sh
 
     user@host:~$ sudo -i # become root
     root@host:~# git clone https://github.com/andsens/bootstrap-vz.git # Clone the repo
@@ -93,7 +93,7 @@ it is recommended to install `the latest docker version <https://docs.docker.com
 VirtualBox Vagrant
 ~~~~~~~~~~~~~~~~~~
 
-.. code:: sh
+.. code-block:: sh
 
     user@host:~$ sudo -i # become root
     root@host:~# git clone https://github.com/andsens/bootstrap-vz.git # Clone the repo
@@ -109,7 +109,7 @@ __ https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_
 Amazon EC2 EBS backed AMI
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. code:: sh
+.. code-block:: sh
 
     user@host:~$ sudo -i # become root
     root@host:~# git clone https://github.com/andsens/bootstrap-vz.git # Clone the repo
@@ -121,7 +121,7 @@ To bootstrap S3 backed AMIs, bootstrap-vz will also need the
 ``euca2ools`` package. However, version 3.2.0 is required meaning you
 must install it directly from the eucalyptus repository like this:
 
-.. code:: sh
+.. code-block:: sh
 
     apt-get install --no-install-recommends python-dev libxml2-dev libxslt-dev gcc zlib1g-dev
     pip install git+git://github.com/eucalyptus/euca2ools.git@v3.2.0

bootstrapvz/README.rst

@@ -11,7 +11,7 @@ dependency graph where directed edges dictate precedence. Each task is
 a simple class that defines its predecessor tasks and successor tasks
 via attributes. Here is an example:
 
-.. code:: python
+.. code-block:: python
 
 	class MapPartitions(Task):
 		description = 'Mapping volume partitions'

bootstrapvz/plugins/admin_user/README.rst

@@ -33,7 +33,7 @@ Settings
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     plugins:

bootstrapvz/plugins/commands/README.rst

@@ -23,7 +23,7 @@ Example
 ~~~~~~~
 
 Create an empty `index.html` in `/var/www` and delete all locales except english.
-.. code:: yaml
+.. code-block:: yaml
 
   commands:
     commands:

bootstrapvz/plugins/opennebula/README.rst

@@ -7,14 +7,14 @@ to the image, which sets up the network configuration and SSH keys.
 
 The virtual machine context should be configured as follows:
 
-::
+.. code-block:: text
 
-    ETH0_DNS      $NETWORK[DNS, NETWORK_ID=2]
-    ETH0_GATEWAY  $NETWORK[GATEWAY, NETWORK_ID=2]
-    ETH0_IP       $NIC[IP, NETWORK_ID=2]
-    ETH0_MASK     $NETWORK[MASK, NETWORK_ID=2]
-    ETH0_NETWORK  $NETWORK[NETWORK, NETWORK_ID=2]
-    FILES         path_to_my_ssh_public_key.pub
+  ETH0_DNS      $NETWORK[DNS, NETWORK_ID=2]
+  ETH0_GATEWAY  $NETWORK[GATEWAY, NETWORK_ID=2]
+  ETH0_IP       $NIC[IP, NETWORK_ID=2]
+  ETH0_MASK     $NETWORK[MASK, NETWORK_ID=2]
+  ETH0_NETWORK  $NETWORK[NETWORK, NETWORK_ID=2]
+  FILES         path_to_my_ssh_public_key.pub
 
 The plugin will install all *.pub* files in the root authorized\_keys
 file. When using the ec2 provider, the USER\_EC2\_DATA will be executed

bootstrapvz/providers/azure/README.rst

@@ -23,7 +23,7 @@ Provider
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/providers/docker/README.rst

@@ -43,7 +43,7 @@ Provider
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     name: bootstrap-vz:latest

bootstrapvz/providers/ec2/README.rst

@@ -53,7 +53,7 @@ under the ``provider`` section.
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:
@@ -78,7 +78,7 @@ __ http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:
@@ -96,7 +96,7 @@ __ http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:
@@ -117,7 +117,7 @@ Image
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/providers/gce/README.rst

@@ -21,7 +21,7 @@ Provider
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/providers/kvm/README.rst

@@ -18,7 +18,7 @@ Provider
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/providers/oracle/README.rst

@@ -28,7 +28,7 @@ generation. They will be used to authenticate the API client.
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:
@@ -52,7 +52,7 @@ available to customize the process of uploading and verifying an image.
    Default: ``false``.
    ``optional``
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/providers/virtualbox/README.rst

@@ -28,7 +28,7 @@ Provider
 
 Example:
 
-.. code:: yaml
+.. code-block:: yaml
 
     ---
     provider:

bootstrapvz/remote/README.rst

@@ -63,7 +63,7 @@ The file ``build-servers.yml`` informs bootstrap-vz about the different
 build servers you have at your disposal.
 In its simplest form you can just add your own machine like this:
 
-.. code:: yaml
+.. code-block:: yaml
 
   local:
     type: local
@@ -94,7 +94,7 @@ Remote settings
 The other (and more interesting) setting for ``type`` is ``ssh``,
 which requires a few more configuration settings:
 
-.. code:: yaml
+.. code-block:: yaml
 
   local_vm:
     type: ssh
@@ -141,7 +141,7 @@ This is useful when for example the VirtualBox guest additions ISO is located
 at ``/root/guest_additions.iso`` on server 1, while server 2 has it at
 ``/root/images/vbox.iso``.
 
-.. code:: yaml
+.. code-block:: yaml
 
   local:
     type: local
@@ -174,7 +174,7 @@ Run settings
 The run settings hold information about how to start a bootstrapped image.
 This is useful only when running system tests.
 
-.. code:: yaml
+.. code-block:: yaml
 
   local:
     type: local

docs/developers/plugins.rst

@@ -12,7 +12,7 @@ Start by creating an ``__init__.py`` in your plugin folder.
 The only obligatory function you need to implement is ``resolve_tasks()``.
 This function adds tasks to be run to the tasklist:
 
-.. code:: python
+.. code-block:: python
 
 	def resolve_tasks(taskset, manifest):
 		taskset.add(tasks.DoSomething)
@@ -23,7 +23,7 @@ check of which release of Debian bootstrap-vz will create an image.
 
 A task is a class with a static ``run()`` function and some meta-information:
 
-.. code:: python
+.. code-block:: python
 
 	class DoSomething(Task):
 		description = 'Doing something'
@@ -46,7 +46,7 @@ process. If you created temporary files for example, you can add a task to the
 rollback taskset that deletes those files, you might even already have it because
 you run it after an image has been successfully bootstrapped:
 
-.. code:: python
+.. code-block:: python
 
 	def resolve_rollback_tasks(taskset, manifest, completed, counter_task):
 		counter_task(taskset, tasks.DoSomething, tasks.UndoSomething)
@@ -63,7 +63,7 @@ running through the completed tasklist and checking each completed task.
 You can also specify a ``validate_manifest()`` function.
 Typically it looks like this:
 
-.. code:: python
+.. code-block:: python
 
 	def validate_manifest(data, validator, error):
 		import os.path
@@ -75,7 +75,7 @@ The schema is a `JSON schema <http://json-schema.org/>`__, since bootstrap-vz
 supports `yaml <http://yaml.org/>`__, you can avoid a lot of curly braces
 quotes:
 
-.. code:: yaml
+.. code-block:: yaml
 
   $schema: http://json-schema.org/draft-04/schema#
   title: Example plugin manifest
@@ -110,7 +110,7 @@ specific to your use-case or when the plugin contains proprietary code that you
 would not like to share.
 They integrate with bootstrap-vz by exposing an entry-point through ``setup.py``:
 
-.. code:: python
+.. code-block:: python
 
 	setup(name='example-plugin',
 	      version=0.9.5,
@@ -123,7 +123,7 @@ They integrate with bootstrap-vz by exposing an entry-point through ``setup.py``
 Beyond ``setup.py`` the package might need a ``MANIFEST.in`` so that assets
 like ``manifest-schema.yml`` are included when the package is built:
 
-.. code::
+.. code-block:: text
 
 	include example/manifest-schema.yml
 	include example/README.rst
@@ -141,6 +141,6 @@ Some plugins may not find their way to the python package index
 (especially if it's in a private repo). They can of course still be installed
 using pip:
 
-.. code:: sh
+.. code-block:: sh
 
 	pip install git+ssh://git@github.com/username/repo#egg=plugin_name

tests/README.rst

@@ -9,7 +9,7 @@ Selecting tests
 ---------------
 To run one specific test suite simply append the module path to tox:
 
-.. code:: sh
+.. code-block:: sh
 
 	$ tox -e unit tests.unit.releases_tests
 
@@ -17,6 +17,6 @@ Specific tests can be selected by appending the function name with a colon
 to the modulepath -- to run more than one tests, simply attach more arguments.
 
 
-.. code:: sh
+.. code-block:: sh
 
 	$ tox -e unit tests.unit.releases_tests:test_lt tests.unit.releases_tests:test_eq

tests/system/README.rst

@@ -46,7 +46,7 @@ Instead of creating manifests from scratch for each single test, reusable parts
 are factored out into partials in the manifest folder.
 This allows code like this:
 
-.. code:: python
+.. code-block:: python
 
 	partials = {'vdi': '{provider: {name: virtualbox}, volume: {backing: vdi}}',
 	            'vmdk': '{provider: {name: virtualbox}, volume: {backing: vmdk}}',

tests/system/providers/README.rst

@@ -28,7 +28,7 @@ up logging and invokes a specific test can be used instead:
 
 Example:
 
-.. code:: python
+.. code-block:: python
 
     #!/usr/bin/env python
 

tox.ini

@@ -32,5 +32,7 @@ commands = nosetests --with-html --html-file=system.html --verbose {posargs:test
 
 [testenv:docs]
 changedir = docs
-deps = sphinx
+deps =
+    sphinx
+    sphinx_rtd_theme
 commands = sphinx-build -W -b html -d _build/html/doctrees . _build/html