puppet 5.3.4 → 6.29.0

data/COMMITTERS.md

@@ -1,244 +0,0 @@
-Committing changes to Puppet
-====
-
-We would like to make it easier for community members to contribute to Puppet
-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](https://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.
-
-It is also the responsibility of the committer to review the change set in an
-effort to make sure the end users must opt-in to new behavior that is
-incompatible with previous behavior.  We employ the use of [feature
-flags](https://stackoverflow.com/questions/7707383/what-is-a-feature-flag) as
-the primary way to achieve this user opt-in behavior.  Finally, it is the
-responsibility of the committer to make sure the `master` and `stable` branches
-are both clean and working at all times.  Clean means that dead code is not
-allowed, everything needs to be usable in some manner at all points in time.
-Stable is not an indication of the build status, but rather an expression of
-our intent that the `stable` branch does not receive new functionality.
-
-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 Puppet 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
-Puppet 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.  The other base branches are
-`stable`, and `security` described below.
-
-**master branch** - The branch where new functionality that are not bug fixes
-is merged.
-
-**stable branch** - The branch where bug fixes against the latest release or
-release candidate are merged.
-
-**security** - Where critical security fixes are merged.  These change sets
-will then be merged into release branches independently from one another. (i.e.
-no merging up).  Please do not submit pull requests against the security branch
-and instead report all security related issues to security@puppetlabs.com as
-per our security policy published at
-[https://puppetlabs.com/security/](https://puppetlabs.com/security/).
-
-Committer Guide
-====
-
-This section provides a guide to follow while committing change sets to Puppet
-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.  These patches will be merged into `master` if they contain new
-functionality.  They will be merged into `stable` and `master` if they fix a
-critical bug.  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, but the patches should
-first be merged into the `security` branch.  Security patches should be merged
-by Puppet Labs staff members.  Pull requests should not be submitted with the
-security branch as the base branch.  Please send all security related
-information or patches to security@puppetlabs.com as per our [Security
-Policy](https://puppetlabs.com/security/).
-
-The CI systems are configured to run against `master` and `stable`.  Over time,
-these branches will refer to different versions, but their name will remain
-fixed to avoid having to update CI jobs and tasks as new versions are released.
-
-How to commit a change set to multiple base branches
----
-
-A change set may apply to multiple branches, for example a bug fix should be
-applied to the stable release and the development branch.  In this situation
-the change set needs to be committed to multiple base branches.  This section
-provides a guide for how to merge patches into these branches, e.g.
-`stable` is patched, how should the changes be applied to `master`?
-
-First, rebase the change set onto the `stable` branch.  Next, merge the change
-set into the `stable` branch using a merge commit.  Once merged into `stable`,
-merge the same change set into `master` without doing a rebase as to preserve
-the commit identifiers.  This merge strategy follows the [git
-flow](http://nvie.com/posts/a-successful-git-branching-model/) model.  Both of
-these change set merges should have a merge commit which makes it much easier
-to track a set of commits as a logical change set through the history of a
-branch.  Merge commits should be created using the `--no-ff --log` git merge
-options.
-
-Any merge conflicts should be resolved using the merge commit in order to
-preserve the commit identifiers for each individual change.  This ensures `git
-branch --contains` will accurately report all of the base branches which
-contain a specific patch.
-
-Using this strategy, the stable branch need not be reset.  Both `master` and
-`stable` have infinite lifetimes.  Patch versions, also known as bug fix
-releases, will be tagged and released directly from the `stable` branch.  Major
-and minor versions, also known as feature releases, will be tagged and released
-directly from the `master` branch.  Upon release of a new major or minor
-version all of the changes in the `master` branch will be merged into the
-`stable` branch.
-
-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 [Puppet FOSS](https://jenkins.puppetlabs.com/view/Puppet%20FOSS/)
-   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 Puppet.  For
-   example, if the most recent release of Puppet is 3.1.1 and you merge a
-   backwards compatible change set into master, then the target version should
-   be 3.2.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 and github
-   will automatically close the pull request when the branch is pushed.)
-
-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 Puppet 3.1.1 which is the most recently released
-version of Puppet.
-
-In this example the committer should rebase the change set onto the `stable`
-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/puppet/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 `stable`.  The committer rebases the change set onto `stable`.
-
-    $ git branch bug/stable/fix_foo_error
-    $ git rebase --onto stable master bug/stable/fix_foo_error
-    First, rewinding head to replay your work on top of it...
-    Applying: (#23456) Fix FooError that always bites users in 3.1.1
-
-The `git rebase` command may be interpreted as, "First, check out the branch
-named `bug/stable/fix_foo_error`, then take the changes that were previously
-based on `master` and re-base them onto `stable`.
-
-Now that we have a topic branch containing the change set based on the `stable`
-release branch, the committer merges in:
-
-    $ git checkout stable
-    Switched to branch 'stable'
-    $ git merge --no-ff --log bug/stable/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 the `stable`
-branch into `master`, being careful to preserve the same commit identifiers.
-
-    $ git checkout master
-    Switched to branch 'master'
-    $ git merge --no-ff --log stable
-    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 into one base branch, the change set should
-not be modified in order to keep the history clean, avoid "double" commits, and
-preserve the usefulness of `git branch --contains`.  If there are any merge
-conflicts, they are to be resolved in the merge commit itself and not by
-re-writing (rebasing) the patches for one base branch, but not another.
-
-Once the change set has been merged into `stable` and into `master`, the
-committer pushes.  Please note, the checklist should be complete at this point.
-It's helpful to make sure your local branches are up to date to avoid one of
-the branches failing to fast forward while the other succeeds.  Both the
-`stable` and `master` branches are being pushed at the same time.
-
-    $ git push puppetlabs master:master stable:stable
-
-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](http://jenkins.puppetlabs.com).

data/MAINTAINERS

@@ -1,66 +0,0 @@
-{
-  "version": 1,
-  "file_format": "This MAINTAINERS file format is described at https://github.com/puppetlabs/maintainers",
-  "issues": "https://tickets.puppet.com/browse/PUP",
-  "internal_list": "https://groups.google.com/a/puppet.com/forum/?hl=en#!forum/discuss-puppet-maintainers",
-  "people": [
-    {
-      "github": "hlindberg",
-      "email": "henrik.lindberg@puppet.com",
-      "name": "Henrik Lindberg"
-    },
-    {
-      "github": "joshcooper",
-      "email": "josh@puppet.com",
-      "name": "Josh Cooper"
-    },
-    {
-      "github": "MikaelSmith",
-      "email": "michael.smith@puppet.com",
-      "name": "Michael Smith"
-    },
-    {
-      "github": "thallgren",
-      "email": "thomas.hallgren@puppet.com",
-      "name": "Thomas Hallgren"
-    },
-    {
-      "github": "branan",
-      "email": "branan@puppet.com",
-      "name": "Branan Riley"
-    },
-    {
-      "github": "Iristyle",
-      "name": "Ethan J. Brown"
-    },
-    {
-      "github": "HAIL9000",
-      "email": "hailee@puppet.com",
-      "name": "Hailee Kenney"
-    },
-    {
-      "github": "er0ck",
-      "email": "eric.thompson@puppet.com",
-      "name": "Eric Thompson"
-    },
-    {
-      "github": "johnduarte",
-      "email": "john.duarte@puppet.com",
-      "name": "John Duarte"
-    },
-    {
-      "github": "adrienthebo",
-      "name": "Adrien Thebo"
-    },
-    {
-      "github": "jtappa",
-      "email": "jorie@puppet.com",
-      "name": "Jorie Tappa"
-    },
-    {
-      "github": "MosesMendoza",
-      "email": "moses@puppet.com",
-      "name": "Moses Mendoza"
-    }
-  ]
-}

data/ext/README.environment

@@ -1,8 +0,0 @@
-This is an example environment directory. The environment's modules can be
-placed in a "modules" subdirectory. The environments initial manifests are
-placed in a "manifests" subdirectory. By default the environment also has any
-modules that are installed globally (normally in /etc/puppetlabs/code/modules) for the
-puppet master.
-
-For more information see
-https://docs.puppet.com/puppet/latest/reference/environments.html

data/ext/autotest/Rakefile

@@ -1,8 +0,0 @@
-dest = File.expand_path("~/.autotest")
-file dest => ["config", "Rakefile"] do
-    sh "cp config #{dest}"
-end
-
-task :install => dest
-
-task :default => :install

data/ext/autotest/config

@@ -1,43 +0,0 @@
-# vim: syntax=ruby
-# From http://pastie.caboo.se/115692, linked from rickbradley
-
-require 'autotest/redgreen'
-require 'autotest/timestamp'
-
-Autotest.send(:alias_method, :real_find_files, :find_files)
-Autotest.send(:define_method, :find_files) do |*args|
-  real_find_files.reject do |k, v|
-    if (ENV['AUTOTEST'] and !ENV['AUTOTEST'].empty?)
-      !Regexp.new(ENV['AUTOTEST']).match(k)
-    end
-  end
-end
-
-module Autotest::Growl
-
-  def self.growl title, msg, img, pri=0, sticky=""
-    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{sticky}"
-  end
-
-  Autotest.add_hook :ran_command do |at|
-    image_root = "~/.autotest_images"
-    results = [at.results].flatten.join("\n")
-    output = results.slice(/(\d+)\stests,\s(\d+)\sassertions,\s(\d+)\sfailures,\s(\d+)\serrors/)
-    if output
-      if $~[3].to_i > 0 || $~[4].to_i > 0
-        growl "FAIL", "#{output}", "#{image_root}/fail.png", 2
-      else
-        growl "Pass", "#{output}", "#{image_root}/pass.png"
-      end
-    end
-
-    output = results.slice(/(\d+)\sexamples,\s(\d+)\sfailures?(,\s+\d+\s+pending)?/)
-    if output
-      if $~[2].to_i > 0 || $~[4].to_i > 0
-        growl "FAIL", "#{output}", "#{image_root}/fail.png", 2
-      else
-        growl "Pass", "#{output}", "#{image_root}/pass.png"
-      end
-    end
-  end
-end

data/ext/autotest/readme.rst

@@ -1,16 +0,0 @@
-Autotest is a simple tool that automatically links tests with the files being
-tested, and runs tests automatically when either the test or code has changed.
-
-If you are running on a Mac and have growlnotify_ installed, install the
-ZenTest_ gem, then copy the ``config`` file to ``~/.autotest`` (or just
-run ``rake`` in this directory).
-
-Once you have ``autotest`` installed, change to the root of your Puppet
-git repository and run ``autotest`` with no arguments.  To refresh the list
-of files to scan, hit ``^c`` (that is, control-c).
-
-It's recommended you leave this running in another terminal during all
-development, preferably on another monitor.
-
-.. _zentest: http://www.zenspider.com/ZSS/Products/ZenTest/
-.. _growlnotify: http://growl.info/extras.php

data/ext/cert_inspector

@@ -1,140 +0,0 @@
-#!/usr/bin/env ruby
-require 'openssl'
-
-class X509Collector
-  include Enumerable
-
-  def initialize
-    @collected_data = {}
-  end
-
-  def interpret_contents(contents)
-    cls = case contents.split("\n")[0]
-          when /BEGIN X509 CRL/ then OpenSSL::X509::CRL
-          when /BEGIN CERTIFICATE REQUEST/ then OpenSSL::X509::Request
-          when /BEGIN CERTIFICATE/ then OpenSSL::X509::Certificate
-          when /BEGIN RSA (PRIVATE|PUBLIC) KEY/ then OpenSSL::PKey::RSA
-          else return nil
-          end
-    cls.new(contents)
-  rescue
-    nil
-  end
-
-  def expected_non_x509_files
-    ['inventory.txt', 'ca.pass', 'serial']
-  end
-
-  def investigate_path(path)
-    if File.directory?(path)
-      Dir.foreach(path) do |x|
-        next if ['.', '..'].include? x
-        investigate_path File.join(path, x)
-      end
-    else
-      contents = File.read path
-      meaning = interpret_contents contents
-      unless meaning || expected_non_x509_files.include?(File.basename(path))
-        puts "WARNING: file #{path.inspect} could not be interpreted"
-      end
-      @collected_data[path] = meaning if meaning
-    end
-  end
-
-  def each(&block)
-    @collected_data.each(&block)
-  end
-
-  def extract_public_key_info(path, meaning)
-    case meaning
-    when OpenSSL::PKey::RSA
-      if meaning.private?
-        [meaning.public_key, 2, path]
-      else
-        [meaning, 3, path]
-      end
-    when OpenSSL::X509::Certificate
-      [meaning.public_key, 0, meaning.subject.to_s]
-    when OpenSSL::X509::Request
-      [meaning.public_key, 1, meaning.subject.to_s]
-    end
-  end
-
-  def who_signed(meaning, key_names, keys)
-    signing_key = keys.find { |key| meaning.verify(key) }
-    if signing_key then "#{key_names[signing_key.to_s]}" else "???" end
-  end
-
-  def explain(meaning, key_names, keys)
-    case meaning
-    when OpenSSL::PKey::RSA
-      if meaning.private?
-        "Private key for #{key_names[meaning.public_key.to_s]}"
-      else
-        "Public key for #{key_names[meaning.public_key.to_s]}"
-      end
-    when OpenSSL::X509::Certificate
-      signature_desc = who_signed(meaning, key_names, keys)
-      "Certificate assigning name #{meaning.subject.to_s} to #{key_names[meaning.public_key.to_s]}\n    serial number #{meaning.serial}\n    issued by #{meaning.issuer.to_s}\n    signed by #{signature_desc}"
-    when OpenSSL::X509::Request
-      signature_desc = who_signed(meaning, key_names, keys)
-      "Certificate request for #{meaning.subject.to_s} having key #{key_names[meaning.public_key.to_s]}\n    signed by #{signature_desc}"
-    when OpenSSL::X509::CRL
-      signature_desc = who_signed(meaning, key_names, keys)
-      revoked_serial_numbers = meaning.revoked.map { |r| r.serial }
-      revoked_desc = if revoked_serial_numbers.count > 0 then "serial numbers #{revoked_serial_numbers.inspect}" else "nothing" end
-      "Certificate revocation list revoking #{revoked_desc}\n    issued by #{meaning.issuer.to_s}\n    signed by #{signature_desc}"
-    else
-      "Unknown"
-    end
-  end
-
-  # Yield unique public keys, with a canonical name for each.
-  def collect_public_keys
-    key_data = {} # pem => (priority, name, public_key)
-    @collected_data.collect do |path, meaning|
-      begin
-        next unless public_key_info = extract_public_key_info(path, meaning)
-        public_key, priority, name = public_key_info
-        pem = public_key.to_s
-        existing_priority, existing_name, existing_public_key = key_data[pem]
-        next if existing_priority and existing_priority < priority
-        key_data[pem] = priority, name, public_key
-      rescue
-        puts "exception!"
-      end
-    end
-    name_to_key_hash = {}
-    key_data.each do |pem, data|
-      priority, name, public_key = data
-      if name_to_key_hash[name]
-        suffix_num = 2
-        while name_to_key_hash[name + " (#{suffix_num})"]
-          suffix_num += 1
-        end
-        name = name + " (#{suffix_num})"
-      end
-      name_to_key_hash[name] = public_key
-    end
-    key_names = {}
-    keys = []
-    name_to_key_hash.each do |name, public_key|
-      key_names[public_key.to_s] = "key<#{name}>"
-      keys << public_key
-    end
-    [key_names, keys]
-  end
-end
-
-collector = X509Collector.new
-ARGV.each do |path|
-  collector.investigate_path(path)
-end
-key_names, keys = collector.collect_public_keys
-collector.map do |path, meaning|
-  [collector.explain(meaning, key_names, keys), path]
-end.sort.each do |description, path|
-  puts "#{path}:"
-  puts "  #{description}"
-  puts
-end

data/ext/dbfix.sql

@@ -1,132 +0,0 @@
--- MySQL DB consistency check/fix
---
--- Usage:
--- cat dbfix.sql | mysql -u user -p puppet
---
--- WARNING: perform a database backup before running this script
-
--- Remove duplicate resources, and keep the latest one
-DELETE bad_rows.*
-FROM resources AS bad_rows
-  INNER JOIN (
-    SELECT title,restype,host_id, MAX(id) as max_id
-    FROM resources
-    GROUP BY title,restype,host_id
-    HAVING count(*) > 1
-  ) AS good_rows
-  ON
-    good_rows.title = bad_rows.title AND
-    good_rows.restype = bad_rows.restype AND
-    good_rows.host_id = bad_rows.host_id AND
-    good_rows.max_id <> bad_rows.id;
-
--- Remove duplicate param_values, and keep the latest one
-DELETE bad_rows.*
-FROM param_values AS bad_rows
-  INNER JOIN (
-    SELECT value,param_name_id,resource_id, MAX(id) as max_id
-    FROM param_values
-    GROUP BY value,param_name_id,resource_id
-    HAVING count(*) > 1
-  ) AS good_rows
-  ON
-    good_rows.value = bad_rows.value AND
-    good_rows.param_name_id = bad_rows.param_name_id AND
-    good_rows.resource_id = bad_rows.resource_id AND
-    good_rows.max_id <> bad_rows.id;
-
--- rewrite param_values that points to duplicated param_names
--- to point to the highest param_name id.
-UPDATE
-  param_values v
-  INNER JOIN
-  param_names n
-  ON n.id = v.param_name_id
-  INNER JOIN
-  (
-    SELECT name, MAX(id) as max_id
-    FROM param_names
-    GROUP BY name
-    HAVING count(*) > 1
-  ) nmax ON n.name = nmax.name
-SET
-  v.param_name_id = nmax.max_id;
-
--- Remove duplicate param_names, and keep the latest one
-DELETE bad_rows.*
-FROM param_names AS bad_rows
-  INNER JOIN (
-    SELECT name, MAX(id) as max_id
-    FROM param_names
-    GROUP BY name
-    HAVING count(*) > 1
-  ) AS good_rows
-  ON
-    good_rows.name = bad_rows.name AND
-    good_rows.max_id <> bad_rows.id;
-
--- Remove duplicate resource_tags, and keep the highest one
-DELETE bad_rows.*
-FROM resource_tags AS bad_rows
-  INNER JOIN (
-    SELECT resource_id,puppet_tag_id, MAX(id) as max_id
-    FROM resource_tags
-    GROUP BY resource_id,puppet_tag_id
-    HAVING count(*) > 1
-  ) AS good_rows
-  ON
-    good_rows.resource_id = bad_rows.resource_id AND
-    good_rows.puppet_tag_id = bad_rows.puppet_tag_id AND
-    good_rows.max_id <> bad_rows.id;
-
--- rewrite resource_tags that points to duplicated puppet_tags
--- to point to the highest puppet_tags id.
-UPDATE
-  resource_tags v
-  INNER JOIN
-  puppet_tags n
-  ON n.id = v.puppet_tag_id
-  INNER JOIN
-  (
-    SELECT name, MAX(id) as max_id
-    FROM puppet_tags
-    GROUP BY name
-    HAVING count(*) > 1
-  ) nmax ON n.name = nmax.name
-SET
-  v.puppet_tag_id = nmax.max_id;
-
--- Remove duplicate puppet_tags, and keep the highest one
-DELETE bad_rows.*
-FROM puppet_tags AS bad_rows
-  INNER JOIN (
-    SELECT name, MAX(id) as max_id
-    FROM puppet_tags
-    GROUP BY name
-    HAVING count(*) > 1
-  ) AS good_rows
-  ON
-    good_rows.name = bad_rows.name AND
-    good_rows.max_id <> bad_rows.id;
-
--- Fix dangling resources
--- note: we use a table to not exceed the number of InnoDB locks if there are two much
--- rows to delete.
--- this is an alternative to: DELETE resources FROM resources r LEFT JOIN hosts h ON h.id=r.host_id WHERE h.id IS NULL;
---
-CREATE TABLE resources_c LIKE resources;
-INSERT INTO resources_c SELECT r.* FROM resources r INNER JOIN hosts h ON h.id=r.host_id;
-RENAME TABLE resources TO resources_old, resources_c TO resources;
-DROP TABLE resources_old;
-
--- Fix dangling param_values
-CREATE TABLE param_values_c LIKE param_values;
-INSERT INTO param_values_c SELECT v.* FROM param_values v INNER JOIN resources r ON r.id=v.resource_id;
-RENAME TABLE param_values TO param_values_old, param_values_c TO param_values;
-DROP TABLE param_values_old;
-
--- Fix dangling resource_tags
-CREATE TABLE resource_tags_c LIKE resource_tags;
-INSERT INTO resource_tags_c SELECT t.* FROM resource_tags t INNER JOIN resources r ON r.id=t.resource_id;
-RENAME TABLE resource_tags TO resource_tags_old, resource_tags_c TO resource_tags;
-DROP TABLE resource_tags_old;

data/ext/debian/README.Debian

@@ -1,8 +0,0 @@
-puppet for Debian
-------------------
-
-The default puppet configuration in Debian will automatically integrate with
-etckeeper if etckeeper is installed. puppet will automatically commit any
-changes made to files in /etc via etckeeper before and after its run.
-
- -- Mathias Gug <mathiaz@ubuntu.com>  Wed, 18 Aug 2010 15:06:06 -0400

data/ext/debian/README.source

@@ -1,2 +0,0 @@
-The debian directory is now maintained on Alioth in git. 
-See https://pkg-puppet.alioth.debian.org/ for more information.

data/ext/debian/TODO.Debian

@@ -1 +0,0 @@
-* clean up initscripts per http://mail.madstop.com/pipermail/puppet-dev/2006-June/001069.html