added the base postflight script for OS X, creating the puppet users and
groups
creating the erb backwards from the postflight script
(Maint) Move initialize near top

The initialize method was hard to find buried down after line 300. This
moves it closer to the top so that a reader of the code and more quickly
see how things are setup.
(Maint) Extract class to encapsulate value translation

The value translation code has been buried deep inside the general
settings handling, which has made it hard to find, reuse, and test. This
pulls out a class that can be used for setting value translation.
(Maint) Extract value translator for settings

Pulled out a class for the translating of values that are going to be
used as settings and added tests around that code.
(Maint) Use value translator directly

This removes an unneeded method that simply called through to the value
translator. There don't seem to be any users outside of the settings.rb
file that were actually using this method.
(Maint) Remove unneeded parse_file method

This method simply delegated to another class. There were no users
outside of the settings.rb file, and so it is just inlined.
(Maint) Remove unused method sectionlist

This method isn't being used anywhere, even in other projects that I
checked.
(Maint) Remove code to support multiple config files

Support for merging config files had been removed, but some of the
supporting code was missed during the removal. This removes the rest of
the support in settings.rb to handle merging multiple config files.
Merge branch 'master' of https://github.com/puppetlabs/puppet
Merge branch 'master' of https://github.com/puppetlabs/puppet
Merge branch 'master' of https://github.com/puppetlabs/puppet
(#7316) Add method to expand autoloaded paths

Several places use an Autoloader to list files that could be loaded
relative to some prefix, e.g. puppet/application. But then the same
prefix is specified again when requiring a specific instance, e.g.

    require File.join('puppet', 'application', name)

This commit adds an Autoload instance method to expand a path, so the
above becomes:

    require @loader.expand(name)
(#15496) Correctly determine timezone offset

A user reported the incorrect offset in reports for hosts
in the timezone "America/Caracas", which is -04:30 from GMT.
The zaml time interpolation did not handle negative fractional
timezones correctly, because Ruby rounds down when integer
division results in a remainder, which caused "-4.5" to result
in "-5".

This patch coerces the denominator into a float, so the printf
formatting's truncation works correctly.
tagmail: s/reportform/reportfrom/

Fix trivial typo in description of the `reportfrom` config option.

This coincides with a similar fix in
`puppet-docs/source/references/*/report.markdown` and is needed
to prevent the typo from propagating into the docs.

Signed-off-by: Paul Morgan <jumanjiman@gmail.com>
(#18041) Remove Autoload.list_loaded method

The list_loaded method was broken in 6700adca in 0.24.0, because the
yielded `hash` parameter was always nil -- we're collecting on a sorted
array of keys, not the `loaded` hash.

Since anyone calling this method would always receive a NoMethodError,
and the code is never called from anywhere in puppet or spec, it is safe
to remove without deprecation.
(#15496) Adds tests for our Time#to_zaml serialization

These exercise the to_zaml monkey-patch to Time by comparing the
output of the method, given a couple of strange (fractional offset,
both east and west of GMT) time zones, against known-good YAML
for the same moment in time -- which happens to be the Mayapocalypse.

Without the fix in d2c816a, the test for the condition in #15496
fails with the same incorrect offset described by the bug author:

  1) Pure ruby yaml implementation should correctly serialize Time objects, even in oddball timezones
     Failure/Error: t.should == serialized
       expected: "--- 2012-12-12 12:12:00.000000 -04:30"
            got: "--- 2012-12-12 12:12:00.000000 -05:30" (using ==)
     # ./spec/unit/util/zaml_spec.rb:56

So this seems likely to be testing the right thing.
(#7316) Refactor listing and requiring of applications

Previously, the logic for listing and requiring applications was in two
places, CommandLine and Application, respectively.

The CommandLine contained logic, basically duplicated from the
Autoloader, to walk a search path and generate a list unique
applications relative to 'puppet/application'.

The Application contained logic for requiring the application from
'puppet/application', duplicating the logic from CommandLine.

This commit moves the logic for listing available applications to the
Application class, which delegates to its autoloader. Note the
autoloader already takes gem and module paths into account, so no change
in functionality there.

This commit also deprecates the CommandLine available_subcomands
instance and class methods.
(#7316) List faces using an autoloader

Previously, calling Puppet::Interface.faces generated a
different list of face applications than those included in
Puppet::Application.available_application_names, since the former only
considered the $LOAD_PATH, and the latter used an Autoloader, which
includes gem directories and the current environment's modulepath.

From what I can tell, the method is never used, as puppet itself
accesses faces via Puppet::Interface[name, version] method. However, if
someone had called `faces` it would have excluded faces that could be
loaded via require.
(#7316) Append module plugin directories to $LOAD_PATH

Previously, face applications delivered as a module could not be loaded.
This is because FaceCollection has problems loading code. For one, it
require's faces and actions within, but load's actions that reside in
different files. So it conceivable that a reloaded face application
could run with older faces, but newer actions.

Second, if we load the face, it will call Puppet::Interface.define,
which will check if the face has already been loaded by calling
FaceCollection[name, version]. But that will attempt to load the face
that we're currently loading, getting into an infinite loop.

Third, the help face application gets a list of available application
names from Application. This list includes applications from gem and
module paths. However, the help face application fails to load faces
which reside in the modulepath, since it's using require and not going
through the Autoloader.

While faces could be modified to use an Autoloader, the longer term plan
is to stop pretending we can reload code in ruby, i.e. always require
based on the current $LOAD_PATH.

This commit adds a `each_plugin_directory` method that yields each
module plugin directories based on the current environment. It also
modifies the CommandLine to append those directories,  unless we are
loading the master or agent applications.

In the case of an agent, the libdir is always in the $LOAD_PATH, and it
will load pluginsync'ed files from there. This aspect of #4248 has been
fixed for sometime.

In the case of master, we compile catalogs in the context of the
client's environment, not necessarily the environment the master itself
is configured to use. As such, we only want to autoload custom functions
from those modules, not require them. In other words, we don't want those
modules in the $LOAD_PATH to start with. This aspect of #4248 (the
ability to load utility module code from a custom function) is not
fixed, and can't really be fixed until we move to one process per
environment compilation.

In the case of apply, we compile catalogs, but always in its current
environment, so we can safely append to the $LOAD_PATH. And same for
face applications. As a result, the help face can load other faces from
modules.