On rebar3's bootstrapping

[Timothée Floure]

Hello,

I have a nasty issue with the erlang-rebar3 (v3.6.2) being unable to build
rebar3 >= 3.7.0 using the system's libraries (see [0] for details).

I wasn't able to properly identify and fix the problem and don't have the time
to do so in the foreseeable future, but I do know that rebar3 3.7.0 >= fix the
issue.  How bad would it be to use bootstrapping to pass the 3.6.2->3.7.0 step?
I don't like it but we don't have a lot of things depending on rebar3 and it
did not reach any stable release yet.

Cheers,

-- 
Timothée

[Randy Barlow]

On Fri, 2019-03-08 at 16:21 +0100, Timothée Floure wrote:
>  I have a nasty issue with the erlang-rebar3 (v3.6.2) being unable to
>  build
>  rebar3 >= 3.7.0 using the system's libraries (see [0] for details).
>  
>  I wasn't able to properly identify and fix the problem and don't have
>  the time
>  to do so in the foreseeable future, but I do know that rebar3 3.7.0
>  >= fix the
>  issue.  How bad would it be to use bootstrapping to pass the 3.6.2-
>  >3.7.0 step?
>  I don't like it but we don't have a lot of things depending on rebar3
>  and it
>  did not reach any stable release yet. 
Hey Timothée!

Can you add the link [0]?

Is this issue known to the upstream? Do we think it's a bug in 3.6?

[Timothée Floure]

Hello,

>  Can you add the link [0]? 
Oops, here it is:

[0] https://kojipkgs.fedoraproject.org//work/tasks/8335/33298335/build.log

>  Is this issue known to the upstream? Do we think it's a bug in
> 3.6? 
The issue seems to be specific to our environment (the Internet, including
upstream, *seems* unaware of the issue):
  * `rebar3 compile` works like a charm fetching dependencies from the Internet
  * `rebar3 bare compile -p $PATHS --separator :` fails with [0]
  * This behavior can be reproduced with both our erlang-rebar3 package and the
    precompiled rebar3 published on github (under releases)

Building a bootstrapped package for rebar3 3.7.x fixes the issue, allowing to
build rebar3 3.7.x, 3.8.x and 3.9.x;

I'm ways too tired to keep staring at my screen - I'm out for the day ;-)

Thanks!

-- 
Timothée

[Randy Barlow]

On Fri, 2019-03-08 at 16:57 +0100, Timothée Floure wrote:
>  The issue seems to be specific to our environment (the Internet,
>  including
>  upstream, *seems* unaware of the issue):
>    * `rebar3 compile` works like a charm fetching dependencies from
>  the Internet
>    * `rebar3 bare compile -p $PATHS --separator :` fails with [0]
>    * This behavior can be reproduced with both our erlang-rebar3
>  package and the
>      precompiled rebar3 published on github (under releases)
>  
>  Building a bootstrapped package for rebar3 3.7.x fixes the issue,
>  allowing to
>  build rebar3 3.7.x, 3.8.x and 3.9.x;
>  
>  I'm ways too tired to keep staring at my screen - I'm out for the day
>  ;-) 
I don't really know Erlang well enough to understand the issue, but
generally maybe a good first step might be to report the issue to the
rebar project to get their take on it. Maybe they can make a new 3.9.z
release that can be built offline with 3.6 for us?

If that doesn't work out, we could ask FESCo for an exception to re-
bootstrap it.

[Peter Lemenkov]

Hello All!
пт, 8 мар. 2019 г. в 16:22, Timothée Floure <timothee.floure(a)fnux.ch&gt;:
>  Hello,
>
>  I have a nasty issue with the erlang-rebar3 (v3.6.2) being unable to build
>  rebar3 >= 3.7.0 using the system's libraries (see [0] for details).
>
>  I wasn't able to properly identify and fix the problem and don't have the time
>  to do so in the foreseeable future, but I do know that rebar3 3.7.0 >= fix the
>  issue.  How bad would it be to use bootstrapping to pass the 3.6.2->3.7.0 step?
Please do. We rebootstrap rebar 2.x several times in the past because
of similar problems, so I don't consider this is the issue.



-- 
With best regards, Peter Lemenkov.