Page MenuHomeFreeBSD

Update lang/elixir to 1.9.0.
AcceptedPublic

Authored by olgeni on Jun 24 2019, 8:40 PM.

Details

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

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 25015
Build 23729: arc lint + arc unit

Event Timeline

olgeni created this revision.Jun 24 2019, 8:40 PM

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.

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...

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.

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 added a comment.EditedJun 26 2019, 8:18 AM

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.

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?

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..

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.

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).

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?

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.

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

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

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 added a comment.EditedJun 27 2019, 2:45 PM

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.

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

Good job ☺️

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

dumbbell accepted this revision.Jul 1 2019, 1:20 PM
This revision is now accepted and ready to land.Jul 1 2019, 1:20 PM
olgeni accepted this revision.Jul 1 2019, 1:21 PM

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!!