If we're building a package for more than one architecture and
the source package provides architecture 'any' *and* 'all' binary
packages at the same time we've to build on all but one
architecture using the -B build option (see dpkg-buildpackage(1)
for details).
Setting MAIN_ARCHITECTURE allows choosing the main architecture,
which is the one providing the "Architecture: all" binary
packages. If unset it defaults to the architecture of the host
system.
Restructure the code to make it less ugly...
Setting TRUNK_RELEASE allows copying each package to
a specific repository so you get a "release-trunk"
feature to point sources.list to a repository featuring
always the latest package versions.
Don't build i386 with "-B" but use the "-b" as well.
Also don't care about arch all vs. arch specific packages during
file removal any longer.
This is supposed to fix configuration matrix builds in Jenkins,
where we're building the package for multiple architectures.
The *-source job in Jenkins will copy the artifacts to
${JENKINS_HOME}/userContent/${JOB_NAME}/ as final action.
Since the *-binary job will take data from there we've to
avoid that outdated data is handed over, so let's get rid
of any existing files before generate-{git,svn}-snapshot job
finishes.
The increase-version-number script nowadays (it exists just as
convenience and backwards-compatibility wrapper) now just appends
"+0" to the specified <version_number> on the command line.
This turned out to be the most reliable way to get:
$existing_old_version < $snapshot_version < $new_version
where $existing_old_version is the provided <version_number>,
$snapshot_version is a version number based on the output of the
script (as used inside scripts like generate-{git,svn}-snapshot)
and $new_version is a version number that might show up in the
future.
I am aware of only one exception where this isn't true with +0
appended for $snapshot. This would be the case when e.g. version
1.2.3 would be changed to 1.2.3-1. But this would mean a change
in Debian packaging as well (from Debian package source being
identical to the pristine source (AKA native package) vs.
upstream software packaged within Debian (AKA non-native
package)). In such a situation the $existing_old_version should
be raised from e.g. 1.2.3 to at least 1.2.3.1-1, otherwise the
generated $snapshot_version will be older than
$existing_old_version until it's 1.2.4, 1.3, etc.
Otherwise accessing the changes file will fail if architecture
is set to "all" and building is done on a amd64 host, since the
changes file is named *_amd64.changes.
Found in an internal build run, showing up as:
svn2cl --reparagraph --stdout --include-rev -r HEAD:6087
runtime error: file /etc/svn2cl/svn2cl.xsl line 432 element param
xsltApplyXSLTTemplate: A potential infinite template recursion was detected.
You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000).
[...]
several times and tons of additional confused error output.
If we have UNRELEASED in the changelog the version number
should not be increased since the version has not been
released yet. Otherwise we'd have a version number in the
autobuild/snapshot version which is higher than the one
that has been officially relased.
${WORKSPACE}/binaries/: we want to separate sources and binaries
so we don't conflict with each other. Therefore put the files we
get from cowbuilder into ${WORKSPACE}/binaries/
remove files of previous runs: we get rid of source files from
previous runs, since Copy Artifact Plugin copies files but if
building fails we find multiple versions inside the workspace.
Since we might want to build older versions as well there is no
simple heuristic we could rely on, therefore get rid of old
files.
handle missing packages: When source package "foo" provides
binary packages "bar" and "baz" in version 0.23 but version 0.42
doesn't provide "baz" any longer, then the no-longer-present
binary package "baz" will stay in the archive since it's not
longer listed in 0.42. In case we even build an version older
than 0.23 providing baz then adding the package will fail at all.
Therefore we get rid of binary packages from the archive that are
no longer build by the current version.
Michael Prokop