Speed up pbuilder: disable building of manual pages with a hook script

Credits: Debian bug #561539
Add execute permissions to D10-man-db
Rework generate-git-snapshot to make sure quilt can't break the build

When using the dpkg 3.0 (quilt) format (see debian/source/format)
there might be quilt patches still applied in the source tree,
either because of a broken build or under certain - though not yet
clearly identified - situations which seem to end with a
"diff: standard output: Broken pipe" message in the build log.

This then might end up in a build failure like:

| + cd /var/lib/jenkins/workspace/glusterfs-source
| + dpkg-source -i -I -b source
| dpkg-source: info: using source format `3.0 (quilt)'
| diff: standard output: Broken pipe
| diff: standard output: Broken pipe
| dpkg-source: info: building glusterfs using existing ./glusterfs_3.2.7.orig.tar.gz
| dpkg-source: info: local changes detected, the modified files are:
|  source/ChangeLog
|  source/doc/gluster.8
|  source/doc/glusterfs.8
|  source/libglusterfs/src/common-utils.c
|  source/rpc/rpc-lib/src/rpcsvc.c
|  source/xlators/mgmt/glusterd/src/glusterd-rpc-ops.c
| dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/glusterfs_3.2.7-2~bpo60+1.diff.3Wkisr
| dpkg-source: info: you can integrate the local changes with dpkg-source --commit

While everything has been cleanly integrated in debian/patches/
the build process fails because it looks like there have been
modifications to upstream sources whereas it's just wrong
information about patches applied.

So instead make sure we enter a clean git repository before doing
any changes (this can be skipped via SKIP_GIT_CLEANUP=true) and
also unapply all present quilt patches (this can be skipped via
SKIP_QUILT_CLEANUP=true). Finally replace the dpkg-source call
with dpkg-buildpackage and its --source-option=--unapply-patches
feature. While the combination of the git cleanup, quilt cleanup
and dpkg-source->dpkg-buildpackage is more than explicitely
necessary this provides more flexibility if needed.

Thanks: Raphael Hertzog <hertzog@debian.org> for his dpkg related feedback
Remove *_source.changes file generated by dpkg-buildpackage in *-source job [Closes: #67]

The recent commit to make sure quilt can't break the build (git
commit 63d6c47) made a switch from dpkg-source to
dpkg-buildpackage. dpkg-buildpackage generates a *_source.changes
file which isn't present when using dpkg-source. While this file
is nice it doesn't provide any real value for us, but what's more
important, it might break existing setups:

If all files are copied around from one Jenkins job to another
then in the final jenkins job the changes file from the binaries
job and the source.changes one end up together. If those are
passed to other tools then things might break (see github issue
67 as an example). So let's just remove the file after the
dpkg-buildpackage call to provide the used behaviour.
build-and-provide-package: Look only for the "real" debian/control file

Otherwise this breaks in a situation like that:

| % tar atf autopkgtest_2.3.5~pgdg70+1.tar.gz | grep control
| -rw-r--r-- 0/0             297 2013-09-25 08:51 source/tests/testpkg/debian/control
| -rw-r--r-- 0/0             151 2013-09-25 08:51 source/debian/tests/control
| -rw-r--r-- 0/0            1982 2013-09-25 08:51 source/debian/control

Thanks: Christoph Berg <christoph.berg@credativ.de> for the bugreport and fix
lintian-junit-report: Use REXML to generate XML output

Parsing lintian output in two runs in order to collect summary of
results had shortcomings - extending the code further to support skipped
tests would require replicating conditional logic in two separate
places. One of the possibilities to fix this would be to keep all but
header output in memory, then print the header and dump the collected
output. However using REXML::Document seemed a better idea resulting in
more readable code. And in fact the change makes the code 5 lines
shorter! ;)

I use REXML::Formatters::Transitive for output, as it preserves exact
text format, even though this makes XML look a bit unusual.
lintian-junit-report: Support for marking tests skipped

This change brings a possibility to mark selected lintian checks as
skipped (in terms of JUnit report). Skipped test cases are considered
less than passed by Jenkins and marked on test result trend, but the
default JUnit results publisher does not set job result to UNSTABLE when
seeing them. Thanks to that you can ignore selected results but still
have them available in the report. The behaviour is controlled by two
new command line options. Example:

lintian-junit-report -w --mark-warnings-skipped \
	--mark-as-skipped=no-debian-copyright,no-copyright-file [...]

Last option takes a list of lintian tags to mark skipped.
Create .mailmap
puppet: install git-client plugin explicitely in version 1.1.2

git-client plugin version 1.3.0 depends on ssh-agent which depends on
credentials plugin version 1.6 or newer. Otherwise it's failing with:

| SEVERE: Failed Loading plugin git-client
| java.io.IOException: Dependency ssh-agent (1.3) doesn't exist

Jenkins LTS 1.509.3 provides Credentials plugin version 1.3.1.
Jenkins 1.534 provides Credentials plugin version 1.4.

Recent versions of the git-client plugin (at least 1.3.0) depend on the
ssh-agent plugin which itself requires version >=1.6 of the Credentials
plugin though, otherwise it's failing with:

| FATAL: com/cloudbees/plugins/credentials/common/StandardCredentials
| java.lang.NoClassDefFoundError: com/cloudbees/plugins/credentials/common/StandardCredentials
|    at org.jenkinsci.plugins.gitclient.Git$1.invoke(Git.java:62)
| [...]

Manually updating the credentials plugin in an automated fashion doesn't
seem to be possible (when placing
http://updates.jenkins-ci.org/latest/credentials.hpi inside the plugin
directory then on Jenkins restart the built-in credentials plugin seems
to always get restored to its old/built-in version).

So unless there's a way to update a built-in plugin besides using the
web interface with its plugin manager we've to install a git-client
plugin version that's known to work without further, unresolvable plugin
dependencies.

Reported upstream as https://issues.jenkins-ci.org/browse/JENKINS-19927
puppet: support forcing plugin installation allowing us to install latest git-client plugin

Related to commit c73c341f ("puppet: install git-client plugin
explicitely in version 1.1.2"), instead of pinning the git-client plugin
to a specific version also install the latest versions of the ssh-agent
and credentials plugins and pin the credentials plugin so it doesn't
get restored/downgraded by Jenkins service itself.

Thanks stephenconnolly for the hint regarding the pinning trick.
See https://issues.jenkins-ci.org/browse/JENKINS-19927
generate-*-snapshot: provide hint if the 'source' directory hasn't been configured

The "Please run the script in the jenkins workspace." itself is
a bit misleading if someone just forgot to configure "source"
directory as the checkout directory.
Merge branch 'feature/git_mailmap' of https://github.com/lkslawek/jenkins-debian-glue
Merge branch 'feature/marking-tests-as-skipped' of https://github.com/lkslawek/jenkins-debian-glue
piuparts_wrapper: quote scriptsdir in piuparts cmd

scriptsdir can be filled by the user and might ends up containing
spaces. Make sure its content is passed as one argument by double
quoting the variable when passing it to the piuparts call.
piuparts_wrapper: unset scripts dir when non existent

On Ubuntu Precise (Long Term Support release), the piuparts script does
not comes with /etc/piuparts/scripts which causes the piuparts output to
report:

 0m0.0s ERROR: Scripts directory is not a directory:
 /etc/piuparts/scripts/

Add a check to make sure it is a directory, if it is not, fallback to an
empty string passed to piuparts.
Make sure to also support linux-any as valid Architecture field

A package which e.g. uses "linux-any" should be handled as
if "any" was set.

Thanks: Jean Baptiste Favre