Merge branch 'ticket/1.7.x/20072_fix_virt_what_redirection' into 1.7.x

* ticket/1.7.x/20072_fix_virt_what_redirection:
  Maint: Colorize spec output on Windows
  (#22072) Execute fully resolved virt-what
  (#20072) Redirect stderr to the correct null device on windows
(#14522) Don't read /proc/self/status on Solaris

/proc/self/status isn't a standard file on Solaris and can't be read as such.
Attempting to read it when using ruby 1.9.3 produces errors such as 'invalid
byte sequence in US-ASCII'. According to
http://www.ruby-forum.com/topic/163804, /proc/self/status is a sparse file with
a map at /proc/self/map to indicate which parts of the file to read. As a
stopgap measure, this commit simply returns false on Solaris, rather than
trying to read the file.
(#14522) Force encoding of data read from /proc/self/status

Without this patch the previous fix for this issue worked well, but was
actually testing and fixing a different problem than described in the
issue.  Reading the /proc/self/status file on Solaris works well,
however the file contents are very different from the Linux platform.
On linux the file contains US-ASCII encoded text which is fully
compatible with our default UTF-8 encoding.  On Solaris, however, the
file is raw data representing the memory space of the process.  This raw
data has no encoding, and as such, causes the invalid byte sequence when
compared with a regular expression.

This patch addresses the problem by forcing the encoding of the string
into UTF-8, removing any invalid characters.  The comparison is not a
problem on MRI versions which do not have `String#encode!`.
Merge branch 'haus-ticket/1.7.x/14522_dont_read_proc_on_solaris' into 1.7.x

* haus-ticket/1.7.x/14522_dont_read_proc_on_solaris:
  (#14522) Force encoding of data read from /proc/self/status
  (#14522) Don't read /proc/self/status on Solaris

closes #421
Maint: Fix order dependent test failure

Previously, executing the following would fail due to order dependent
test failures:

  rspec spec/unit/util/virtual_spec.rb spec/unit/util/macaddress_spec.rb
  rspec spec/unit/util/virtual_spec.rb spec/unit/util/uptime_spec.rb

This occurs because rspec filters were being used on describe blocks,
but those values are not cleared up between examples.

This commit instead filters the tests based on
Facter::Util::Config.is_windows?

It also removes duplicate expectations on kernel value
(packaging) Update FACTERVERSION to 1.7.0-rc2
(packaging) Update FACTERVERSION to 1.7.0
(packaging) Add raring to the default cows list

Raring will be released near the end of April, so this commit adds it to the
list of cows to build against.
(packaging) Remove f16 from mocks to build as it is EOL

Fedora 16 went EOL 02-12-2013, so this commit removes it from the mocks to be
built against.
Merge pull request #427 from haus/update_cows_mocks

Update cows mocks
(#14522) Force /proc/self/status encoding to valid UTF-8 (try 2)

Without this patch the previous attempt to fix issue 14522 is
insufficient because the String#encode method is a no-op when the source
and destination encodings are the same encoding, even if there are
invalid byte sequences.

This is a problem because we're still getting unhandled `invalid byte
sequence in UTF-8` errors running the specs.

This patch addresses the problem by changing encoding from UTF-8 to
UTF-16, replacing all invalid byte sequences with the default unicode
string of "uFFFD"  We then convert back to UTF-8 to guarantee only valid
byte sequences remain.
(#20236) Add example that reproduces dmidecode issue

Without this patch we don't have an example that reproduces the issue
described in 20236.  This is a problem because we don't automatically
know when we've fixed the issue.

This patch addresses the problem by adding a single example that
reproduces the issue described in 20236; dmidecode is not consulted when
the lspci command returns data but does not result in a determination of
the virtual platform.
(#20236) Refactor the virtual fact and fix dmidecode

Without this patch there are a ridiculous number of problems with the
virtual fact.  This patch reduces the number of problems to something
more along the lines of an absurd number of problems.

The major problem this patch addresses is that a single local variable,
`result`, is used to store the determined-thus-far value of the virtual
fact.  Sometimes this value is checked to see if it's still at the
initial value of 'physical'.  Only sometimes, however, most of the time
subsequent platform checks blindly overwrite the value even if we've
already made a determination.

This patch addresses the problem by using the `next` keyword to return a
value from the block passed to `setcode` as soon as a value is
determined.  Only if all attempts have failed do we resort to returning
'physical'  This patch completely eliminates the use of the `result`
accumulator that is constantly being overwritten.

As part of this change in behavior, the bug described in #20236 is
resolved because we no longer fail to check `dmidecode` if the output of
`lspci` does not result in a determination.

Surprisingly, the spec tests pass with almost no modification, the one
exception being an unexpected invocation on a mocked object resulting
from a confinement check added by this patch.  This leads me to believe
this is a true refactor, or as close to one as we're going to get.

The patch does change the behavior substantially.  If multiple results
could be determined without this patch applied then Facter would return
the value of the last determination.  With this patch applied Facter
will return the first determined result.  It's unclear which behavior is
expected of the system, the spec tests do not express an expected
behavior in this scenario.  The comments at the top of virtual.rb lead
us to believe the first result should be returned, implying this patch
gets us a little closer to correct behavior.  I suspect there will be
issues filed regardless of which way we go.  There certainly have been
no end to the number of issues filed against the virtual fact thus far.
Merge remote-tracking branch 'pr/429' into 1.7.x

This closes GH-429
(maint) Use RSpec 2.9 expectations

We have RSpec 2.11 listed in the project Gemfile but CI is still using
2.9. This commit switches the expectation syntax to the older version
for compatibility.
Merge branch 'maint-rspec_29_compat' into 1.7.x
Maint: Don't load rubygems in application code

Previously, loading the `Facter::Util::Config` module had the side
effect of loading rubygems, which leads to unpredictable behavior when
facter is used as a library (as opposed to an application via
bin/facter).

This commit removes the require 'rubygems' call so that an external
application can require 'facter' without the ill side-effect.