Unlike redhat, debian stores env files in '/etc/default'. We need to be able to search there in order to access them. This commit adds that search path to the systemd service file. Note that this works because the service doesn't depend on the existance of those files. So, on redhat, neither '/etc/default/puppet' nor '/etc/default/puppetagent' will exist, but the service will continue to run regardless.
- When running specs in our local Jenkins environment, the 'extra' gems, which include 'msgpack' are not installed. We do this because: - 'msgpack' requires building native code, which unnecessarily adds to the feedback loop - we intentionally try to maintain a clean environment without the Ruby DevKit installed This has previously worked on AppVeyor because they have the Ruby DevKit installed.
Previously, tests executed in a platform-specific order in appveyor, and if an order dependent failure happened, we didn't know what the order was. This commit sets the `LOG_SPEC_ORDER` environment variable which causes puppet's spec helper to write each spec to `spec_order.txt` in the project root. It also adds an `on_failure` handler to archive the file, which can then be downloaded from the job's Artifacts tab.
…/ubuntu releases With the release of Debian 8 (Jessie) and Ubuntu 15.04 (Vivid Vervet), ubuntu and debian now default to systemd as the main service manager, rather than init or upstart. This commit updates Puppet to use systemd as the default service provider on these two systems, while also defaulting back to other service providers if necessary. Additionally, there is a bug on debian systemd where it is unable to correctly detect SysV style services. This commit also adds in a workaround to correctly detect `is-enabled` for these services.  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751638
Commit 345da4d removed use of facter 2.x's 'ps' fact in favor of picking the proper 'ps' invocation in the base provider. However, it introduced two bugs around the usage of getpid: 1) it made getpid private (which makes sense) but left an unneeded use of 'self.getpid' in the code (this can just be 'getpid') 2) the refactoring left a reference to an abandoned local variable, 'ps', in a debug message (this can be restored) This commit fixes those two bugs.
* upstream/stable: (PUP-3829) : call 'pip' instead of 'pip-python' on RedHat > 6 in the pip package provider (docs) Generate man pages (PUP-2630) Ensure $server_facts works with apply (PUP-2630) Populate $server_facts during puppet apply (docs) Revise description of trusted_server_facts setting (maint) Fix for PUP-4483. (PUP-4552) Use TypeCalculator.infer_set for type validation errors Conflicts: spec/integration/application/apply_spec.rb
* upstream/3.x: (PUP-3829) : call 'pip' instead of 'pip-python' on RedHat > 6 in the pip package provider (maint) Fix for PUP-4483. (PUP-4552) Use TypeCalculator.infer_set for type validation errors Conflicts: lib/puppet/resource.rb spec/integration/parser/future_compiler_spec.rb spec/unit/provider/package/pip_spec.rb lib/puppet/resource.rb was changed in 3.x to call `TypeCalculator.infer_set`, but it occurs in a `if !Puppet.future_parser?` block. It conflicted, because the `future_parser?` predicate doesn't exist in stable, and the change to use `infer_set` was already done in stable. Kept call to `infer_set`. spec/integration/parser/future_compiler_spec.rb was modified in 3.x, but no longer exists in stable, and the test was already implemented in stable's spec/integration/parser/compiler_spec.rb. Removed future_compiler_spec.rb. spec/unit/provider/package/pip_spec.rb was backported to 3.x, but the original commit used rspec 2 style expectations, which were later fixed in stable, but not included in the backport (since 3.x doesn't require rspec 3). Updated test to use rspec 3 expectations.
* upstream/pr/3948: (PUP-3829) : call 'pip' instead of 'pip-python' on RedHat > 6 in the pip package provider
Previously we were depending on the "use-el-extras" feature of Beaker but we were not taking full advantage of its ability to point at an EPEL mirror. We have sporadically seen failures based on the availability of the mirrors at kernel.org. This commit infers if we are running within the internal network by looking for a well known environment variable and, if so, adds the appropriate beaker configuration to use our internal epel mirror.
…pip package provider
For package providers, the base package provider was defaulting to a property hash with a status of :absent when the package was missing. When the resource is `ensure => purged`, an :absent status causes it to be purged. This is because an absent package could represent a "partially installed" package that is not truly installed and can therefore be purged (see the dpkg provider). If the base provider always returns a status of :absent for missing packages then purgeable providers will always attempt to purge a missing resource. The fix is to have the base provider default to a :purged status when the resource is missing and the provider supports purging. Otherwise, it defaults to :absent like before.