facter 2.5.7 → 3.9.6.cfacter.20180606

data/COMMITTERS.md

@@ -1,185 +0,0 @@
-Committing changes to Facter
-====
-
-We would like to make it easier for community members to contribute to facter
-using pull requests, even if it makes the task of reviewing and committing
-these changes a little harder.  Pull requests are only ever based on a single
-branch, however, we maintain more than one active branch.  As a result
-contributors should target their changes at the master branch. This makes the
-process of contributing a little easier for the contributor since they don't
-need to concern themselves with the question, "What branch do I base my changes
-on?"  This is already called out in the [CONTRIBUTING.md](http://goo.gl/XRH2J).
-
-Therefore, it is the responsibility of the committer to re-base the change set
-on the appropriate branch which should receive the contribution.
-
-The rest of this document addresses the concerns of the committer.  This
-document will help guide the committer decide which branch to base, or re-base
-a contribution on top of.  This document also describes our branch management
-strategy, which is closely related to the decision of what branch to commit
-changes into.
-
-Terminology
-====
-
-Many of these terms have more than one meaning.  For the purposes of this
-document, the following terms refer to specific things.
-
-**contributor** - A person who makes a change to facter and submits a change
-set in the form of a pull request.
-
-**change set** - A set of discrete patches which combined together form a
-contribution.  A change set takes the form of Git commits and is submitted to
-facter in the form of a pull request.
-
-**committer** - A person responsible for reviewing a pull request and then
-making the decision what base branch to merge the change set into.
-
-**base branch** - A branch in Git that contains an active history of changes
-and will eventually be released using semantic version guidelines.  The branch
-named master will always exist as a base branch.  All other base branches will
-be associated with a specific released version of facter, e.g. 1.6.x and 1.7.x.
-
-Committer Guide
-====
-
-This section provides a guide to follow while committing change sets to facter
-base branches.
-
-How to decide what release(s) should be patched
----
-
-This section provides a guide to help a committer decide the specific base
-branch that a change set should be merged into.
-
-The latest minor release of a major release is the only base branch that should
-be patched. Older minor releases in a major release do not get patched. Before
-the switch to [semantic versions](http://semver.org/) committers did not have
-to think about the difference between minor and major releases.  Committing to
-the latest minor release of a major release is a policy intended to limit the
-number of active base branches that must be managed.
-
-Security patches are handled as a special case.  Security patches may be
-applied to earlier minor releases of a major release.
-
-How to commit a change set to multiple base branches
----
-
-A change set may apply to multiple releases.  In this situation the change set
-needs to be committed to multiple base branches.  This section provides a guide
-for how to merge patches across releases, e.g. 2.7 is patched, how should the
-changes be applied to 3.0?
-
-First, merge the change set into the lowest numbered base branch, e.g. 2.7.
-Next, merge the changed base branch up through all later base branches by using
-the `--no-ff --log` git merge options.  We commonly refer to this as our "merge
-up process" because we merge in once, then merge up multiple times.
-
-When a new minor release branch is created (e.g. 3.1.x) then the previous one
-is deleted (e.g. 3.0.x). Any security or urgent fixes that might have to be
-applied to the older code line is done by creating an ad-hoc branch from the
-tag of the last patch release of the old minor line.
-
-Code review checklist
----
-
-This section aims to provide a checklist of things to look for when reviewing a
-pull request and determining if the change set should be merged into a base
-branch:
-
- * All tests pass
- * Are there any platform gotchas? (Does a change make an assumption about
-   platform specific behavior that is incompatible with other platforms?  e.g.
-   Windows paths vs. POSIX paths.)
- * Is the change backwards compatible? (It should be)
- * Are there YARD docs for API changes?
- * Does the change set also require documentation changes? If so is the
-   documentation being kept up to date?
- * Does the change set include clean code?  (software code that is formatted
-   correctly and in an organized manner so that another coder can easily read
-   or modify it.)  HINT: `git diff master --check`
- * Does the change set conform to the contributing guide?
-
-
-Commit citizen guidelines:
----
-
-This section aims to provide guidelines for being a good commit citizen by
-paying attention to our automated build tools.
-
- * Don’t push on a broken build.  (A broken build is defined as a failing job
-   in the [Facter](https://jenkins.puppetlabs.com/view/Facter/)
-   page.)
- * Watch the build until your changes have gone through green
- * Update the ticket status and target version.  The target version field in
-   our issue tracker should be updated to be the next release of facter.  For
-   example, if the most recent release of facter is 1.6.17 and you merge a
-   backwards compatible change set into master, then the target version should
-   be 1.7.0 in the issue tracker.)
- * Ensure the pull request is closed (Hint: amend your merge commit to contain
-   the string `closes #123` where 123 is the pull request number.
-
-Example Procedure
-====
-
-This section helps a committer rebase a contribution onto an earlier base
-branch, then merge into the base branch and up through all active base
-branches.
-
-Suppose a contributor submits a pull request based on master.  The change set
-fixes a bug reported against facter 1.7.1 which is the most recently released
-version of facter.
-
-In this example the committer should rebase the change set onto the 1.7.x
-branch since this is a bug rather than new functionality.
-
-First, the committer pulls down the branch using the `hub` gem.  This tool
-automates the process of adding the remote repository and creating a local
-branch to track the remote branch.
-
-    $ hub checkout https://github.com/puppetlabs/facter/pull/1234
-    Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
-    Switched to a new branch 'jeffmccune-fix_foo_error'
-
-At this point the topic branch is a descendant of master, but we want it to
-descend from 1.7.x.  The committer creates a new branch then re-bases the
-change set:
-
-    $ git branch bug/1.7.x/fix_foo_error
-    $ git rebase --onto 1.7.x master bug/1.7.x/fix_foo_error
-    First, rewinding head to replay your work on top of it...
-    Applying: (#23456) Fix FooError that always bites users in 1.7.1
-
-The `git rebase` command may be interpreted as, "First, check out the branch
-named `bug/1.7.x/fix_foo_error`, then take the changes that were previously
-based on `master` and re-base them onto `1.7.x`.
-
-Now that we have a topic branch containing the change set based on the correct
-release branch, the committer merges in:
-
-    $ git checkout 1.7.x
-    Switched to branch '1.7.x'
-    $ git merge --no-ff --log bug/1.7.x/fix_foo_error
-    Merge made by the 'recursive' strategy.
-     foo | 0
-     1 file changed, 0 insertions(+), 0 deletions(-)
-     create mode 100644 foo
-
-Once merged into the first base branch, the committer merges up:
-
-    $ git checkout master
-    Switched to branch 'master'
-    $ git merge --no-ff --log 1.7.x
-    Merge made by the 'recursive' strategy.
-     foo | 0
-     1 file changed, 0 insertions(+), 0 deletions(-)
-     create mode 100644 foo
-
-Once the change set has been merged "in and up." the committer pushes.  (Note,
-the checklist should be complete at this point.)  Note that both the 1.7.x and
-master branches are being pushed at the same time.
-
-    $ git push puppetlabs master:master 1.7.x:1.7.x
-
-That's it!  The committer then updates the pull request, updates the issue in
-our issue tracker, and keeps an eye on the build status.

data/CONTRIBUTING.md

@@ -1,91 +0,0 @@
-# How to contribute
-
-Third-party patches are essential for keeping facter great. We simply can't
-access the huge number of platforms and myriad configurations for running
-facter. We want to keep it as easy as possible to contribute changes that
-get things working in your environment. There are a few guidelines that we
-need contributors to follow so that we can have a chance of keeping on
-top of things.
-
-## Getting Started
-
-* Make sure you have a [Jira account](http://tickets.puppetlabs.com)
-* Make sure you have a [GitHub account](https://github.com/signup/free)
-* Submit a ticket for your issue, assuming one does not already exist.
-  * Clearly describe the issue including steps to reproduce when it is a bug.
-  * Make sure you fill in the earliest version that you know has the issue.
-* Fork the repository on GitHub
-
-## New Facts
-
-All new facts should also be included in `schema/facter.json`. Without this facts won't pass acceptance tests.
-
-## Making Changes
-
-* Create a topic branch from where you want to base your work.
-  * This is usually the master branch.
-  * Only target release branches if you are certain your fix must be on that
-    branch.
-  * To quickly create a topic branch based on master; `git branch
-    fix/master/my_contribution master` then checkout the new branch with `git
-    checkout fix/master/my_contribution`.  Please avoid working directly on the
-    `master` branch.
-* Make commits of logical units.
-* Check for unnecessary whitespace with `git diff --check` before committing.
-* Make sure your commit messages are in the proper format.
-
-````
-    (#99999) Make the example in CONTRIBUTING imperative and concrete
-
-    Without this patch applied the example commit message in the CONTRIBUTING
-    document is not a concrete example.  This is a problem because the
-    contributor is left to imagine what the commit message should look like
-    based on a description rather than an example.  This patch fixes the
-    problem by making the example concrete and imperative.
-
-    The first line is a real life imperative statement with a ticket number
-    from our issue tracker.  The body describes the behavior without the patch,
-    why this is a problem, and how the patch fixes the problem when applied.
-````
-
-* Make sure you have added the necessary tests for your changes.
-* Run _all_ the tests to assure nothing else was accidentally broken.
-
-## Making Trivial Changes
-
-### Documentation
-
-For changes of a trivial nature to comments and documentation, it is not
-always necessary to create a new ticket in Jira. In this case, it is
-appropriate to start the first line of a commit with '(doc)' instead of
-a ticket number.
-
-````
-    (doc) Add documentation commit example to CONTRIBUTING
-
-    There is no example for contributing a documentation commit
-    to the Facter repository. This is a problem because the contributor
-    is left to assume how a commit of this nature may appear.
-
-    The first line is a real life imperative statement with '(doc)' in
-    place of what would have been the ticket number in a
-    non-documentation related commit. The body describes the nature of
-    the new documentation or comments added.
-````
-
-## Submitting Changes
-
-* Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla).
-* Push your changes to a topic branch in your fork of the repository.
-* Submit a pull request to the repository in the puppetlabs organization.
-* Update your ticket to mark that you have submitted code and are ready for it to be reviewed.
-  * Include a link to the pull request in the ticket
-
-# Additional Resources
-
-* [More information on contributing](http://links.puppetlabs.com/contribute-to-puppet)
-* [Bug tracker (Jira)](http://tickets.puppetlabs.com)
-* [Contributor License Agreement](http://links.puppetlabs.com/cla)
-* [General GitHub documentation](http://help.github.com/)
-* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
-* #puppet-dev IRC channel on freenode.org

data/Gemfile

@@ -1,69 +0,0 @@
-source ENV['GEM_SOURCE'] || 'https://artifactory.delivery.puppetlabs.net/artifactory/api/gems/rubygems/'
-
-def location_for(place, fake_version = nil)
-  if place =~ /^(git[:@][^#]*)#(.*)/
-    [fake_version, { :git => $1, :branch => $2, :require => false }].compact
-  elsif place =~ /^file:\/\/(.*)/
-    ['>= 0', { :path => File.expand_path($1), :require => false }]
-  else
-    [place, { :require => false }]
-  end
-end
-
-# C Ruby (MRI) or Rubinius, but NOT Windows
-platforms :ruby do
-  gem 'watchr', :group => :development
-  gem 'pry', :group => :development
-  gem 'yard', :group => :development
-  gem 'redcarpet', '<= 2.3.0', :group => :development
-end
-
-group :development, :test do
-  gem 'yarjuf', "~> 1.0"
-  gem 'rake', "~> 10.1.0"
-  gem 'rspec', "~> 2.11.0"
-  gem 'mocha', "~> 0.10.5"
-  gem 'json', "~> 1.7", :platforms => :ruby
-  gem 'json-schema', "~> 2.6.2", :platforms => :ruby
-  gem 'puppetlabs_spec_helper'
-end
-
-gem 'packaging', *location_for(ENV['PACKAGING_LOCATION'] || '~> 0.99') if RUBY_VERSION.to_f >= 2.3
-
-require 'yaml'
-data = YAML.load_file(File.join(File.dirname(__FILE__), 'ext', 'project_data.yaml'))
-bundle_platforms = data['bundle_platforms']
-data['gem_platform_dependencies'].each_pair do |gem_platform, info|
-  next if gem_platform =~ /mingw/
-  if bundle_deps = info['gem_runtime_dependencies']
-    bundle_platform = bundle_platforms[gem_platform] or raise "Missing bundle_platform"
-    platform(bundle_platform.intern) do
-      bundle_deps.each_pair do |name, version|
-        gem(name, version, :require => false)
-      end
-    end
-  end
-end
-
-mingw = [:mingw]
-mingw << :x64_mingw if Bundler::Dsl::VALID_PLATFORMS.include?(:x64_mingw)
-
-platform(*mingw) do
-  # FFI dropped 1.9.3 support in 1.9.16, and 1.9.15 was an incomplete release.
-  # 1.9.18 is required to support Ruby 2.4
-  if RUBY_VERSION.to_f < 2.0
-    gem 'ffi', '<= 1.9.14', :require => false
-  elsif RUBY_VERSION.to_f < 2.6
-    gem 'ffi', '~> 1.9.18', :require => false
-  else
-    gem 'ffi', '~> 1.10', :require => false
-  end
-end
-
-gem 'facter', ">= 1.0.0", :path => File.expand_path("..", __FILE__)
-
-if File.exists? "#{__FILE__}.local"
-  eval(File.read("#{__FILE__}.local"), binding)
-end
-
-# vim:ft=ruby

data/LICENSE

@@ -1,15 +0,0 @@
-Facter - Host Fact Detection and Reporting
-
-Copyright 2005-2014 Puppet Labs Inc
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.

data/README.md

@@ -1,65 +0,0 @@
-Facter
-======
-
-This package is largely meant to be a library for collecting facts about your
-system.  These facts are mostly strings (i.e., not numbers), and are things
-like the output of `uname`, public ssh keys, the number of processors, etc.
-
-See `bin/facter` for an example of the interface.
-
-Installation
-------------
-
-Generally, you need the following things installed:
-
-* A supported Ruby version. Ruby 1.8.7, 1.9.3, and 2.0.0 (at least p195) are fully supported.
-
-Running Facter
---------------
-
-Run the `facter` binary on the command for a full list of facts supported on
-your host.
-
-Adding your own facts
----------------------
-
-See the [Adding Facts](http://docs.puppetlabs.com/guides/custom_facts.html)
-page for details of how to add your own custom facts to Facter.
-
-Running Specs
--------------
-
-* bundle install --path .bundle/gems
-* bundle exec rake spec
-
-Note: external facts in the system facts.d directory can cause spec failures.
-
-Further Information
--------------------
-
-See http://www.puppetlabs.com/puppet/related-projects/facter for more details.
-
-Support
--------
-Please log tickets and issues at our [JIRA tracker](http://tickets.puppetlabs.com).  A [mailing
-list](https://groups.google.com/forum/?fromgroups#!forum/puppet-users) is
-available for asking questions and getting help from others. In addition there
-is an active #puppet channel on Freenode.
-
-We use semantic version numbers for our releases, and recommend that users stay
-as up-to-date as possible by upgrading to patch releases and minor releases as
-they become available.
-
-Bugfixes and ongoing development will occur in minor releases for the current
-major version. Security fixes will be backported to a previous major version on
-a best-effort basis, until the previous major version is no longer maintained.
-
-
-For example: If a security vulnerability is discovered in Facter 2.1.0, we
-would fix it in the 2 series, most likely as 2.1.1. Maintainers would then make
-a best effort to backport that fix onto the latest Facter 1.7 release.
-
-Long-term support, including security patches and bug fixes, is available for
-commercial customers. Please see the following page for more details:
-
-[Puppet Enterprise Support Lifecycle](http://puppetlabs.com/misc/puppet-enterprise-lifecycle)

data/Rakefile

@@ -1,46 +0,0 @@
-# We need access to the Puppet.version method
-$LOAD_PATH.unshift(File.expand_path("lib"))
-require 'facter/version'
-
-RAKE_ROOT = File.expand_path(File.dirname(__FILE__))
-
-$LOAD_PATH << File.join(RAKE_ROOT, 'tasks')
-
-require 'rake'
-Dir['tasks/**/*.rake'].each { |t| load t }
-
-['rubygems', 'rspec', 'rspec/core/rake_task','rcov', 'packaging'].each do |lib|
-  begin
-    require lib
-  rescue LoadError
-  end
-end
-
-#load packaging tasks
-Pkg::Util::RakeUtils.load_packaging_tasks if defined?(Pkg)
-
-namespace :package do
-  task :bootstrap do
-    puts 'Bootstrap is no longer needed, using packaging-as-a-gem'
-  end
-  task :implode do
-    puts 'Implode is no longer needed, using packaging-as-a-gem'
-  end
-end
-
-if defined?(RSpec::Core::RakeTask)
-  desc "Run all specs"
-  RSpec::Core::RakeTask.new do |t|
-    t.pattern ='spec/{unit,integration}/**/*_spec.rb'
-    t.fail_on_error = true
-  end
-
-  RSpec::Core::RakeTask.new('spec:rcov') do |t|
-    t.pattern ='spec/{unit,integration}/**/*_spec.rb'
-    t.fail_on_error = true
-    if defined?(Rcov)
-      t.rcov = true
-      t.rcov_opts = ['--exclude', 'spec/*,test/*,results/*,/usr/lib/*,/usr/local/lib/*,gems/*']
-    end
-  end
-end