It looks like RPM on SLES 11 fails to handle GPG v4 signatures, even
though it happily signed it:
# rpm -K -vvv ./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm
./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm:
Header V4 RSA/SHA1 signature: BAD, key ID 6026dfca
Header SHA1 digest: OK (895933d0ba5eca00759ebdfaa0d4e5d156ad0985)
V4 RSA/SHA1 signature: BAD, key ID 6026dfca
MD5 digest: OK (422c5b455a0f63055d5cd8701da8064b)
After forcing a GPG v3 signature, the signature check is successful:
# rpm -v -K ./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm
./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm:
Header SHA1 digest: OK (a9235a3ec1f7a893bd1fe2ec20c011542cfe88d4)
MD5 digest: OK (fd555d5b73180efcb8232f1f0a5a8a61)
[#150792874]
This matches the distribution name and version we want to target (i.e.
SLES 11). In the future, we might want to also create an SLES 12
package.
Also, enable the new package in the default build. Before this, the
default target (`all`) would call `package-rpm-opensuse`. So
`package-rpm-suse` and `package-rpm-opensuse1012` were unused.
While here, the RPM-specific targets were reworked a bit. Here is the
dependency tree:
package
`-- package-rpm
|-- package-rpm-redhat
| |-- package-rpm-rhel6
| `-- package-rpm-rhel7
`-- package-rpm-suse
|-- package-rpm-opensuse
`-- package-rpm-sles11
For some reason, package-rpm-fedora isn't called at all. I don't know
why, this needs to be investigated.
This reverts part of commit 851561953a.
We need to hard-code the dependency on init-system-helpers to support
Ubuntu 14.04.
(cherry picked from commit 12d2edad42)
... which are added by debhelper. In this case, this is
init-system-helpers which is added by dh-systemd.
While here, bump the standard version to 3.9.6.
(cherry picked from commit 851561953a)
... which are added by debhelper. In this case, this is
init-system-helpers which is added by dh-systemd.
While here, bump the standard version to 3.9.6.
Recent openSUSE releases have been migrated to systemd so use the
%{suse_version} macro to detect if we are building on openSUSE
so we can include the necessary systemd files and also perform the
needed systemd steps. This also defines the 'suse_version' to 1315
which is what openSUSE Leap 42.x use. This also drops the buggy rhel7
conditional for the sysvinit script and use another 'find' command
instead. The previous condition was wrong since it would also try
to include the sysvinit file on openSUSE and Fedora which do not
define the %rhel macro and as such the 0 < 7 conditional was always
true.
(cherry picked from commit 2211e5fe44)
Shortcuts for `rabbitmq-service.bat` should run as admin
because system control tools require admin.
Also make shortcuts run a command prompt and do not exit if there
is an error, so the error can be seen by an operator.
Part of rabbitmq/rabbitmq-server#1324
[#149953545]
In the old release build script, Erlang is already provided. However in
CI, Erlang is installed later in the Makefile recipe. Thus, display its
version only once we are sure Erlang is available.
(cherry picked from commit 5cb41b9434)
This should help us diagnose situations where the version of Erlang used
to compile is greater than the minimum supported.
(cherry picked from commit 679518f911)
In the old release build script, Erlang is already provided. However in
CI, Erlang is installed later in the Makefile recipe. Thus, display its
version only once we are sure Erlang is available.
systemd considers that, when the ExecStop commands exit, the service is
stopped. If there are remaining processes in the cgroup, they are
killed.
Unfortunately, `rabbitmqctl stop` doesn't wait for the Erlang VM to
exit, it just notifies RabbitMQ to stop. Because it doesn't wait,
systemd kills other processes such as `erl_child_setup`. When this
happens, the Erlang VM crashes (because it can't reach `erl_child_setup`
anymore) and the service enters the failed state in systemd. Note the
"erl_child_setup closed" message in the following output:
[root@ip-172-31-29-47 package-testing]# systemctl status rabbitmq-server
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2017-07-31 14:54:42 UTC; 1s ago
Process: 26763 ExecStop=/usr/sbin/rabbitmqctl stop (code=exited, status=0/SUCCESS)
Process: 26398 ExecStart=/usr/sbin/rabbitmq-server (code=exited, status=1/FAILURE)
Main PID: 26398 (code=exited, status=1/FAILURE)
Status: "Initialized"
Jul 31 14:54:30 ip-172-31-29-47 rabbitmq-server[26398]: completed with 0 plugins.
Jul 31 14:54:40 ip-172-31-29-47 systemd[1]: Stopping RabbitMQ broker...
Jul 31 14:54:41 ip-172-31-29-47 rabbitmqctl[26763]: Stopping and halting node 'rabbit@ip-172-31-29-47'
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: Gracefully halting Erlang VM
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: erl_child_setup closed
Jul 31 14:54:42 ip-172-31-29-47 rabbitmq-server[26398]: Crash dump is being written to: erl_crash.dump...done
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service: main process exited, code=exited, status=1/FAILURE
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Stopped RabbitMQ broker.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Unit rabbitmq-server.service entered failed state.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service failed.
Now, we add a second ExecStop which simply waits for the Erlang VM PID
to disappear. This looks to fix the issue.
[#149807109]
The erlang-* 1:16.b.3 packages family (note the absence of the package
revision) was only partially uploaded to the Erlang Solutions Debian
repository... For instance, we have erlang-nox 1:16.b.3 and 1:16.b.3-3,
but only erlang-base 1:16.b.3-3 :-/
[#131645781]
We use mk-build-deps(1) from the `devscripts` package to help us with
this. This helper script looks at `debian/control` and creates a
meta-package which depends on the build dependencies. Then we only have to
install it to get those dependencies.
We only do this if `$(INSTALL_BUILD_DEPS)` is set to `yes`. We want to
use this feature in CI, but not with the old build script where we cheat
a lot around Erlang and Elixir packages.
[#131645781]
Recent openSUSE releases have been migrated to systemd so use the
%{suse_version} macro to detect if we are building on openSUSE
so we can include the necessary systemd files and also perform the
needed systemd steps. This also defines the 'suse_version' to 1315
which is what openSUSE Leap 42.x use. This also drops the buggy rhel7
conditional for the sysvinit script and use another 'find' command
instead. The previous condition was wrong since it would also try
to include the sysvinit file on openSUSE and Fedora which do not
define the %rhel macro and as such the 0 < 7 conditional was always
true.
The `PRODUCTVERSION` must be four integers. So try to replace
everything following the first three integers in the the
semver-formatted `$(VERSION)` by `.0`. For instance if `$(VERSION)` is
`3.6.8+1.g1dcb221`, `PRODUCTVERSION` will be set to `3.6.8.0`.
This should make Windows installer builds successful out-of-the-box.
This is still possible to override this behavior by setting the
`$(PRODUCT_VERSION)` Make variable.
[#142391637]
This boot script is required by escript(1). Without it, escript(1) fails
with the following error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
init terminating in do_boot ()
[#141679931]
(cherry picked from commit 7ffe744d66)
The problem is that xargs(1) has a limit on the number of bytes
it reads on stdin and we reach it. This leads to an archive
containing half of the expected files and xargs(1) never complains.
We apply the same fix which was previously appled in commit
b9dd874671.
[#141674113]
(cherry picked from commit 178fa534ea)
This boot script is required by escript(1). Without it, escript(1) fails
with the following error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
init terminating in do_boot ()
[#141679931]
The problem is that xargs(1) has a limit on the number of bytes
it reads on stdin and we reach it. This leads to an archive
containing half of the expected files and xargs(1) never complains.
We apply the same fix which was previously appled in commit
b9dd874671.
[#141674113]
The `standalone-linux-x86_64` package will be used as a base for our BOSH
release. At least we'll experiment with this approach.
The `standalone-freebsd-x86_64` package is mostly for my local tests.
[#141141909]
The RPM's changelog is now updated automatically if no entry match the
version being built. This is being handled by the parse-changelog.sh and
update-changelog.sh scripts.
Both VERSION and RPM_VERSION are still accepted. If the latter is
unspecified, it is derived from VERSION.
Package signing is now handled here, instead of the Umbrella. This makes
this Makefile on par with the Debian package's Makefile. This Makefile
still accepts KEYSDIR or GNUPG_PATH, but they are deprecated: one should
simply set GNUPGHOME.
In the end, the Makefile is still compatible with the current way of
building a RabbitMQ release but it will simplify the job of Concourse.
As a bonus, there is a new script called compare-rpm-versions.py: it
compares two given versions (including the package revision) using RPM.
This helps when testing versioning.
[#131645695]
The `check-changelog.sh` script is transformed to `update-changelog.sh`.
It doesn't care anymore if $UNOFFICIAL_RELEASE is set or not. It simply
verifies if the given version matches the last entry of
`debian/changelog` (without taking the package revision into account).
If the last entry doesn't match, it prepends a new automatically
generated entry.
Also, the Makefile takes both `VERSION` and `DEBIAN_VERSION` as input
variables. `VERSION` is the RabbitMQ version (eg. `3.6.7-alpha.62`)
and `DEBIAN_VERSION` is the same version formatted for Debian (eg.
`3.6.7~lpha.62`). If the latter is missing, it's computed from `VERSION`.
Regarding package signing, `GNUPG_PATH` is deprecated. The caller should
instead directly use `GNUPGHOME`, the documented variable expected by
GnuPG.
In the end, the Makefile is still compatible with the current way of
building a RabbitMQ release but it will simplify the job of Concourse.
As a bonus, there are two new scripts:
o scripts/get-debian-package-files-list.sh: List all files making a
Debian package, based on a specified `.changes` file.
o scripts/compare-debian-versions.py: Compare two given versions
(including the package revision) using APT. This helps when testing
versioning.
[#131645209]
Otherwise erl.diff cannot be applied:
patch -o rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl.src < erl.diff
patch: **** Can't create file rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl : Permission denied
The default mode of `$prefix/lib/erlang/bin/erl` is 0755.
Because we compile Erlang from sources as part of a release build, there
is no issue. Debian and FreeBSD packages follow the official mode too,
so when testing on those, it still works. However, Homebrew changes the
mode to 0555, which breaks our `Makefile` expectation.
Otherwise erl.diff cannot be applied:
patch -o rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl.src < erl.diff
patch: **** Can't create file rabbitmq_server-3.7.0.milestone8/release/rabbitmq_server-3.7.0.milestone8/erts-8.2/bin/erl : Permission denied
The default mode of `$prefix/lib/erlang/bin/erl` is 0755.
Because we compile Erlang from sources as part of a release build, there
is no issue. Debian and FreeBSD packages follow the official mode too,
so when testing on those, it still works. However, Homebrew changes the
mode to 0555, which breaks our `Makefile` expectation.
With this patch it's possible to run `dpkg-buildpackage` any number
number of times from single source directory. Otherwise `dpkg-source`
thinks that sources were modified and fails to execute.
`clean-unpacked-source-dist` is needed because `make clean` doesn't
descend into `deps/` folder, and doing `make clean APPS_DIR=deps` breaks
on `licensing/` which doesn't have makefile.
Calling `patch-sockjs` is necessary to be sure that no files in source dist
tarball will not be touched during build.
Our packaging Makefiles already take care of not exporting `DEPS_DIR`.
This is to make sure a user setting (eg. `DEPS_DIR` set globally in the
environment) doesn't break the package build either.
A Debian package is built with a Makefile, `debian/rules`. This Makefile
inherited all variables defined on the command line, even though we
unexported the dangerous ones.
We need to unset `MAKEOVERRIDES` to prevent GNU Make from passing them
in `MAKEFLAGS`.
Everything comes from the rabbitmq-server repository. The goals of this
move are:
1. separate unrelated files: the broker sources and release
handling comprising plugins;
2. resolve an important dependency cycle: plugins depend on the
broker to run, but the broker depends on plugins to build a
release.
[#130659985]
Jean-Sébastien Pédron
Michael Klishin
Gabriele Santomaggio
Luke Bakken
Michael Klishin
Michael Klishin
Markos Chandras
Daniil Fedotov
Michael Klishin
Daniil Fedotov
Gerhard Lazu
Jean-Sébastien Pédron
Loïc Hoguin
Alexey Lebedeff
Alexey Lebedeff