Update lang/elixir to 1.9.0.

[olgeni]

Summary

Update lang/elixir to 1.9.0. It doesn't seem dangerous.

Test Plan

Things that come to mind..

• Check if it bothers other ports in some way, like net/rabbitmq
• Library ports should probably go away at some point

[olgeni]

I got this with RabbitMQ...

`gmake[2]: Leaving directory '/wrkdirs/usr/ports/net/rabbitmq/work/rabbitmq-server-3.7.15/deps/rabbit_common'
gmake[2]: Entering directory '/wrkdirs/usr/ports/net/rabbitmq/work/rabbitmq-server-3.7.15/deps/rabbit'
gmake[3]: Entering directory '/wrkdirs/usr/ports/net/rabbitmq/work/rabbitmq-server-3.7.15/deps/rabbitmq_cli'
GEN escript/rabbitmqctl
Could not find Hex, which is needed to build dependency :json
Shall I install Hex? (if running non-interactively, use "mix local.hex --force") [Yn] ** (Mix) httpc request failed with: {:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], :eaddrnotavail}]}

Could not install Hex because Mix could not download metadata at https://repo.hex.pm/installs/hex-1.x.csv.`

Everything's ok with 1.8.2, so the new lang/elixir is missing something apparently.

[dumbbell]

Hi!

I suppose RabbitMQ is compiled offline like in Poudriere in your case?

I will try to reproduce. The RabbitMQ CI builds test packages offline, but currently not with Elixir 1.9.0.

Speaking with my RabbitMQ hat, so far, it's been quite a nightmare to put Elixir dependencies in the source archive so it is self-contained and buildable offline. I added ugly machinery to our Makefile to trick mix(1) and I'm not surprised it breaks...

[dumbbell]

I couldn't reproduce the issue. I added Elixir 1.9.0 in the RabbitMQ packaging CI to make sure we catch that error, but so far it succeeds.

[olgeni]

In D20748#449160, @dumbbell wrote:

I couldn't reproduce the issue. I added Elixir 1.9.0 in the RabbitMQ packaging CI to make sure we catch that error, but so far it succeeds.

Does the CI have network access during the build? Maybe I just have to add some distfiles - I'll check.

[dumbbell]

To be exact, it does have network but no DNS configured. So far, it was enough to catch any issue with the source archive missing some bits.

[olgeni]

In D20748#449164, @dumbbell wrote:

To be exact, it does have network but no DNS configured. So far, it was enough to catch any issue with the source archive missing some bits.

Could you check if a different version of hex is being downloaded in some way? maybe in the build logs?

[olgeni]

I ran "gmake source-dist" in rabbitmq-server-release and got a new tarball with a new hex version, but I get the same error :)

Something changed upstream so that it will always try to download some of the stuff..

[dumbbell]

Trying to reproduce inside Poudriere (with the Elixir update patch from this review + RabbitMQ patch to accept Elixir 1.9.0). I will keep you posted.

[dumbbell]

I see the failure in Poudriere and I now understand the problem: Poudriere sets $HOME in the environment and as a Make variable. And setting it as a Make variable defeats my brilliant hack to convince mix(1) it has everything locally already. This is something we don't do in the RabbitMQ CI. I will add that right away so our test environment is closer to package builders' one.

And of course let me find an even hackier workaround, I always cherish those moments with mix(1).

[olgeni]

In D20748#449240, @dumbbell wrote:

I see the failure in Poudriere and I now understand the problem: Poudriere sets $HOME in the environment and as a Make variable. And setting it as a Make variable defeats my brilliant hack to convince mix(1) it has everything locally already. This is something we don't do in the RabbitMQ CI. I will add that right away so our test environment is closer to package builders' one.

I did some odd things with HOME in rebar3 and relx and I managed to fool it somehow. Perhaps it just wants an up-to-date mirror of the hex.pm cache file?

[dumbbell]

There is a copy of the cache in the source archive. RabbitMQ's Makefile messes with $HOME in particular to point mix(1) to that copy.

[dumbbell]

Ok, setting $HOME on the Make command line in CI is enough to reproduce the failure. I can now work on the workaround.

[dumbbell]

The RabbitMQ CI is green again, but Poudriere is still unhappy. Investigating...

[dumbbell]

Apparently, mix(1) now uses $XDG_CONFIG_HOME and $XDG_DATA_HOME variables, before $HOME, to determine its own directory. Poudriere also explicitly set them, which defeats our workaround. Again, I adapted our CI and will prepare another workaround.

[dumbbell]

Ok, the last patch worked: Poudriere is happy, RabbitMQ CI is happy, I'm happy, everyone is happy!

I will prepare a review for the patch to net/rabbitmq: D20781.

[olgeni]

In D20748#449629, @dumbbell wrote:

Ok, the last patch worked: Poudriere is happy, RabbitMQ CI is happy, I'm happy, everyone is happy!

Good job ☺️

[dumbbell]

I committed the patch to make RabbitMQ compatible with Elixir 1.9.0 (D20781). Hopefully this will unblock the work on this update.

[olgeni]

In D20748#450763, @dumbbell wrote:

I committed the patch to make RabbitMQ compatible with Elixir 1.9.0 (D20781). Hopefully this will unblock the work on this update.

I committed this one but forgot to quote the review id :|

Seems to be working fine so far. Thanks!!