New versions of Salt put config files in /etc/salt/{minion,master}.d. We don't
want to erase them by using a clean: True on the file.recurse. This is a
backward incompatible change, but it's necessary to avoid deleting Salt config
files.

Resolves #104

Using a variable named salt is a bad idea when salt already has a variable
named salt.

fixes #83 by wrapping contents of pkgrepo/init.sls in an {% if %}.

Change-Id: I8260fdf5cf802c0b28197516da374add6c3002a2

This will fix #39

And it will be backwards compatible with the current pillar configuration.

see pillar.example for configuration

This is necessary for the correct settings on the minions when saltifying new hosts

updated the map style without the base='default' parameter

Update sls files to match name change in map.jinja.

Added map.jinja solution more in line with other formulas,
This also improves issue #30

and pull request #30

If those options are set in pillar data, the jinja template
salt/files/master.d/_defaults.conf would fail to compile trying to
evaluate non-existing variables.

Replace those variables with the corresponding dictionnary entries.

This is only needed for salt versions older than 2014.7 that do not
define the global "salt" variable in such context.

Most include do not expect salt to be something else than the usual salt
variable giving access to all the salt modules. Instead we use cfg_salt.
And for consistency we rename the master/minion variables to
cfg_master/cfg_minion too.

This commit also provides a more concrete example of a 'host' to
be saltified.  Users can do

    salt-cloud -p make_salty someinstance

or

    salt-cloud -m /etc/salt/cloud.maps.d/foo.conf

Either which way the online docs should really be updated with more
concrete examples.

In Python 3, dict.items() is already an iterator while dict.iteritems() no
longer exits. In Python 2, dict.items() is not an iterator but it works
and the small performance hit doesn't really matter for the salt config
pillar data which is really small.

Otherwise you get an “ValueError: too many values to unpack” exception
when you make use of those entries in your pillar data.

This state downloads formulas from git repositories and ensures
that they are recorded in the file_roots setting.

This state enables the official saltstack package repository in order to
always benefit from the latest version. This state currently only works on
Debian and Ubuntu, and aims to implement the installation recommendations
of the official documentation:
http://docs.saltstack.com/en/latest/topics/installation/index.html

Fixed explanations, and improved logic code to client_acl

better newlines with iterations.

This will make the _defaults.conf file for master and minion
better by removing some empty lines in some code blocks

Updated gitfs jinja, to mirror master file

Gitfs for the minion is possible with salt 2014.7
Updated config _defaults.conf and pillar with example
Tested it on Archlinux with salt-call --local state.highstate

I don't understand why unnecessary ``-`` were added after and before ``{%-`` and ``-%}``

https://github.com/saltstack-formulas/salt-formula/issues/64

Fixes issue where a gitfs remote that has no child options would cause an
error. Also fix up bad yaml in pillar example.

Commit 2b51a6f0c3 introduced options for gitfs_remotes in a pillar by using a jinja test to see if a parameter is a mapping (dict etc.). This feature however is only available in jinja 2.6 or newer (see http://jinja.pocoo.org/docs/dev/templates/#mapping).
Although this version of Jinja is available on Ubuntu, other OS / package managers do provide older versions (2.2.1 in RedHat 6).

This change makes use of the "iterable" test which should do the exact same thing.

Reference about this config value: http://docs.saltstack.com/en/latest/ref/configuration/master.html#yaml-utf8
Reference why this might be useful: https://github.com/saltstack/salt/issues/3436#issuecomment-61225863

Fixing typo

Removing crypto pip dependency for the ``os_family`` ``Debian``.

Refer to PR:
https://github.com/saltstack-formulas/salt-formula/pull/60#issuecomment-62029457

Fixes:
https://github.com/saltstack-formulas/salt-formula/issues/59

Refer to PR:
https://github.com/saltstack-formulas/salt-formula/pull/60

It doesn't seem to be available from pip anymore, and may not be
a real dependency. Salt-cloud certainly seems to work fine without
it.