=ERROR REPORT==== 21-Jul-2017::07:14:51 === Loading of /usr/bin/rebar/rebar/ebin/rebar.beam failed: badfile escript: exception error: undefined function rebar:main/1 in function escript:run/2 (escript.erl, line 760) in call from escript:start/1 (escript.erl, line 277) in call from init:start_em/1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0_libressl_20170716-132702 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python3.6 (fallback) [3] python3.5 (fallback) [4] python2.7 (fallback) java-config: The following VMs are available for generation-2:
Created attachment 486292 [details] emerge-info.txt
Created attachment 486294 [details] dev-erlang:eredis-1.0.8:20170721-051449.log
Created attachment 486296 [details] emerge-history.txt
Created attachment 486298 [details] environment
Created attachment 486300 [details] etc.portage.tbz2
Created attachment 486302 [details] temp.tbz2
Hello, This bug and bug 625876, bug 626018, bug 626066, bug 626270, bug 626560, bug 626718, bug 626890, bug 626984, bug 627104, bug 627128, bug 627158, bug 627410, bug 627472, bug 627524, and bug 625740; that is, the majority of the bugs returned by a query against "dev-erlang" on the Gentoo bug tracker as of the date of this post, all seem to suffer from a common cause. The relevant line, located in the emerge log of each package, is: > Loading of /usr/bin/rebar/rebar/ebin/rebar.beam failed: badfile In every case I could find this seems to be caused by a mismatch of Erlang interpreter and code version, i.e. running new code on an old interpreter. However, I also expect a line like the following, which is not present: > beam/beam_load.c(1365): Error loading module rebar: > use of opcode 153; this emulator supports only up to 152 Based on the original error (badfile) I think it should be clear that rebar is either not available or the wrong version. Checking the emerge history of the tinderbox guest it is not clear as to what is actually wrong. Most instances of this error seem to "spontaneously" resolve themselves as the reporter reinstalls the entire Erlang/OTP stack. Consequently this leads me to recommend a reinstallation of all of the packages in question, but it is my understanding that tinderbox does this already. There may also be misconfiguration in Erlang/OTP, however, only one report I found actually was resolved in this way, and it was for Windows/OTP17 (symbolic links not resolving properly). Can some explanation of what the tinerbox guest is doing be offered? R0b0t1.
(In reply to R030t1 from comment #7) Sure, the tinderbox mainly does this in each chroot: "qsearch --all | sort --random-sort | xargs -n 1 emerge --update" and just parses the output as described in [1]. The script is about 20 lines starting from [2]. The setup of a chroot image is very straight forward as described in the WIKI. Feel free to contact me at IRC, I'm living in the timezone Berlin/Germany and will stay usually in the early evening at IRC. [1] https://zwiebeltoralf.de/tinderbox.html [2] https://github.com/toralf/tinderbox/blob/master/bin/job.sh#L1162
Thank you for the explanation. It looks like there is persistent state on the tinderbox guests but it is not kept long. In any case I can't reproduce this, bug 625740, or bug 627410 on a fresh installation and am left to conclude that the guests are improperly configured in some way. Three might be enough of a trend to close the bugs you have submitted, but I can test all of the packages that reportedly have rebar issues if you want me to.
(In reply to R030t1 from comment #9) >>hat the guests are improperly configured in some way. I appreciate any hints and tipps how to properly setup a guest for Erlang & friends. Feel free to contact me on #IRC or so. For now I'll try to not continue to spam bug reports as long as the root cause isn't clear.
(In reply to Toralf Förster from comment #10) > (In reply to R030t1 from comment #9) > >>hat the guests are improperly configured in some way. > > I appreciate any hints and tipps how to properly setup a guest for Erlang & > friends. Feel free to contact me on #IRC or so. For now I'll try to not > continue to spam bug reports as long as the root cause isn't clear. It is doubtful I have any special knowledge about the process. I am actually very interested in what is broken, but I do not have much of an idea on how to follow up on it. The improper configuration is likely nothing intentional. Does creating a guest with the same emerge history produce the error?
yes
Created attachment 494108 [details] emerge-info.txt
Created attachment 494110 [details] dev-erlang:riak_pb-2.2.0.2:20170912-011157.log
Created attachment 494112 [details] emerge-history.txt
Created attachment 494114 [details] environment
Created attachment 494116 [details] etc.portage.tbz2
Created attachment 494118 [details] temp.tbz2
and here is another example from an image cloned all properties from the origin
Created attachment 494120 [details] emerge-info.txt
Created attachment 494122 [details] dev-erlang:stun-1.0.10:20170910-194737.log
Created attachment 494124 [details] emerge-history.txt
Created attachment 494126 [details] environment
Created attachment 494128 [details] etc.portage.tbz2
Created attachment 494130 [details] temp.tbz2
FWIW the image 13.0-desktop_libressl_20170903-100751 have 4 failing erlang packages till now: tinderbox@mr-fox ~/img1/13.0-desktop_libressl_20170903-100751/tmp/issues $ ls -ld *erlang* drwxrwxrwx 3 root root 205 Sep 12 09:47 20170910-214904_dev-erlang_stun-1.0.10 drwxrwxrwx 3 root root 253 Sep 12 09:43 20170912-030752_dev-erlang_hamcrest-0.1.0_p20160709 drwxrwxrwx 3 root root 253 Sep 12 09:45 20170912-031328_dev-erlang_riak_pb-2.2.0.2 drwxrwxrwx 3 root root 174 Sep 12 03:20 20170912-031900_dev-erlang_riakc-2.4.2
I can't reproduce those on hardened amd64. Is there any way you can let me interact with a Tinderbox guest? It is hard to interpret the information supplied non-interactively. I expect I will have to look at the filesystem of the guests.
*** Bug 625740 has been marked as a duplicate of this bug. ***
*** Bug 626066 has been marked as a duplicate of this bug. ***
*** Bug 626018 has been marked as a duplicate of this bug. ***
*** Bug 626560 has been marked as a duplicate of this bug. ***
*** Bug 626984 has been marked as a duplicate of this bug. ***
*** Bug 627158 has been marked as a duplicate of this bug. ***
*** Bug 627524 has been marked as a duplicate of this bug. ***
*** Bug 638054 has been marked as a duplicate of this bug. ***
*** Bug 688018 has been marked as a duplicate of this bug. ***
*** Bug 689764 has been marked as a duplicate of this bug. ***
*** Bug 627054 has been marked as a duplicate of this bug. ***
*** Bug 627404 has been marked as a duplicate of this bug. ***
*** Bug 625876 has been marked as a duplicate of this bug. ***
*** Bug 626718 has been marked as a duplicate of this bug. ***
*** Bug 626890 has been marked as a duplicate of this bug. ***
*** Bug 627104 has been marked as a duplicate of this bug. ***
*** Bug 627128 has been marked as a duplicate of this bug. ***
*** Bug 627410 has been marked as a duplicate of this bug. ***
*** Bug 627472 has been marked as a duplicate of this bug. ***
*** Bug 638062 has been marked as a duplicate of this bug. ***
*** Bug 690332 has been marked as a duplicate of this bug. ***
*** Bug 691158 has been marked as a duplicate of this bug. ***
*** Bug 691254 has been marked as a duplicate of this bug. ***
*** Bug 692338 has been marked as a duplicate of this bug. ***
Marking all identical bugs that seem to happen on every rebar package as duplicate. Can't reproduce this either, so not sure what to do. Toralf, do these still appear? Otherwise I'd close this bug for now.
dev-erlang/eredis emerged fine today
I believe this and all similar bugs should be covered by the subslot changes to the rebar eclass that should make sure we always rebuild for the right erlang version.
