This should limit number of possible node names generated by and with that
prevent atom space exhaustion in ejabberd process.
On R23+ we switch to using native dynamic node features and on older
versions we iterate over small number of possible names and skip those
already in use.
With setup-beam v1.17.2, make-binaries failed in the Container action with:
* ERROR: No usable Erlang/OTP system for the build machine found! Cannot
* cross compile without such a system.
*
* Either build a bootstrap system for the build machine, or provide
* an Erlang/OTP-26 system in the $PATH, and try again. For more
* information on cross compiling Erlang/OTP-26, see the
* $ERL_TOP/xcomp/README file.
The problematic commit is:
cf854bf149
more concretely this change:
- core.exportVariable(installDirForVarName, cachePath)
+ core.exportVariable(installDirForVarName, catchPathBin)
Up until setup-beam@v1.17.1, the INSTALL_DIR_FOR_OTP was something like
/opt/hostedtoolcache/otp/ubuntu-22.04/OTP-26.1.1/x64
but starting in v1.17.2, the path contains /bin, for example:
/opt/hostedtoolcache/otp/ubuntu-22.04/OTP-26.1.1/x64/bin
Ignore XEP-0334 elements when checking whether a stanza is a stand-alone
XEP-0085 chat state notification. This allows for CSI-filtering chat
states with (e.g.) a no-store hint.
Thanks to Thilo Molitor for reporting the issue.
The file `src/install-sh` was added in c311ea1.
Most files from that commit were removed in 4d8f770 and install-sh was moved.
Since recent commit 7cae092, `./configure` checks for a race-free `mkdir -p`,
the `install-sh` script may be used, and it needs execution permission.
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"
