That option is required when Erlang < 26 to disable the archive feature.
The feature and the option were removed in Erlang 26, and the release
building process fails if the option is used.
https://www.erlang.org/patches/otp-26.0
When --enable-tools, include observer and runtime_tools
in the OTP releases, as they are required by "ejabberdctl etop".
With this fix, "ejabberdctl etop" works correctly when:
* rebar3 + make rel
* mix + make dev
* mix + make rel
Rebar2 could create a release, so it made sense to call it "make rel".
Nowadays, Rebar3 and Mix support creating different types of releases:
production, development, ...
In this sense, our "make rel" target is more properly named "make prod"
For backwards compatibility, "make rel" redirects to "make prod"
Use the program specified in option: --with-rebar=/path/to/bin
When none is specified, use the system mix
When Elixir not found, use the system rebar3
When Rebar3 not found, use the rebar3 binary included with ejabberd
Adding ejabberd_po to gitonly_deps isn't strictly needed,
because we request a branch in the ejabberd-po git repository,
and rebar.config.script understands that this means ejabberd_po
should be downloaded from git, not hex.pm.
Elixir is standalone since years ago. When Elixir support is required,
better simply install Elixir and use Mix as build tool.
Or install Elixir and use the experimental Rebar3 support to compile
Elixir files and dependencies.
The problem appeared when:
./configure --with-rebar=mix
make install
ejabberdctl live
=INFO REPORT==== 19-Dec-2023::21:28:36.006306 ===
application: ssl
exited: stopped
type: temporary
...
configure.ac by default enables stun and zlib, in fact ejabberd.yml
has ejabberd_stun enabled by default, so for coherence mix.exs should
enable stun too when vars.config is not found.
Looks like clients using strophejs aren't able to authenticate when we
add data required by that spec to scram packets, so at least give a way
to disable this until clients will be fixed.
If stream management is enabled, let mod_ping trigger XEP-0198
<r/>equests rather than sending XEP-0199 pings. This avoids the
overhead of the ping IQ stanzas, which, if stream management is enabled,
are accompanied by XEP-0198 elements anyway.
Thanks to MoyaApp (<https://moya.app>) for sponsoring this work.
