rebar3 is the successor for rebar which has huge adoption in Erlang development.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
I started to work on some of the erlang dependencies for rebar3 (the specfiles can be found on fedorapeople ) and will create a copr repository once I finish to package them all. I might submit them to the official repo once everything works properly. Are you okay with that ?
I successfully built (the package may need some more work to be "clean") all of rebar3's dependencies: see copr repository .
It should be possible to build and install rebar3 with rebar 2.x, but it is easier (I successfully did it) to use a prebuilt binary of rebar3 for the initial build while I still have troubles with rebar 2.x (note that I am not familiar with rebar). However, we fall into the "bootstrapping" exeption of the packaging guidelines. What do you think ? Can you take a look ?
I started down this path and basically ended up where you are now. It would be better to be able to bootstrap rebar3 using rebar 2.x, but I just gave up and used a bootstrap rebar3 build from upstream releases.
We "crossed" Peter a few times last month while working on elixir's package, but we were unable to exchange with him even through he applied some of our patches:
I really would like him to respond to this bug, or at least someone from the erlang SIG. I feel like I'm sailing blind !
If I still fail to contact the peter/the erlang SIG, I most likely will ask devel@ and go forward with rebar3 packaging in a few weeks.
I just send a mail to devel@, trying to contact Peter: https://firstname.lastname@example.org/thread/B7WRRTWBMJLCMUHK7XJRB7WLVEPTQ4AE/
(In reply to John Eckersberg from comment #4)
> I started down this path and basically ended up where you are now. It would
> be better to be able to bootstrap rebar3 using rebar 2.x, but I just gave up
> and used a bootstrap rebar3 build from upstream releases.
Yes, I think it's better (faster, and easier for us) to start from scratch rather than relying on rebar2 for boostrapping.
(In reply to Peter Lemenkov from comment #7)
> (In reply to John Eckersberg from comment #4)
> > I started down this path and basically ended up where you are now. It would
> > be better to be able to bootstrap rebar3 using rebar 2.x, but I just gave up
> > and used a bootstrap rebar3 build from upstream releases.
> Yes, I think it's better (faster, and easier for us) to start from scratch
> rather than relying on rebar2 for boostrapping.
Thanks for the response! Then I will submit the related packages for reviews during the next few days (currently backpacking on my way to flock). I will gladly add anyone as co-maintainer once the packages reach the stable repositories.
Bootstrap exception request: https://pagure.io/packaging-committee/issue/788
Quick update: all the dependencies are in rawhide and I'm currently trying to have rebar3 to use the system's erlang libraries.
Upstream bug: https://github.com/erlang/rebar3/issues/1855
The packaging committee approved the bootstrap exception a few weeks ago. I'll try to take a look this weekend but I don't have a lot of time this month and would gladly accept some help.
I finally found some time to work on this bug and got a somewhat working rebar3 package locally. I will submit a proper package within a few days :-)
There is currently an erlang-rebar3 package in rawhide and I'm working to update it to the latest upstream version. The current version works but make a lot of calls to the network and we can't use it as-is for packaging: I'm also working on it but it will take some time since I have a lot of other things to work on.
You'll find some details on the wiki page of the SIG  and I will open a few bugs on RHBZ in order to track the mentionned issues.