R9C-0 is out ... the ebuild is going to have to be re-versioned in order to take into account the way erlang version tags their releases ... since their releases over the last year have been: R7B-0, R7B-1, R7B-2, R7B-3, R7B-4, R8B-0, R8B-1, R8B-2, R9B-0, R9B-1, R9C-0 i would suggest the following portage to erlang matching: R7B-0: 7.0b R7B-1: 7.1b R7B-2: 7.2b R7B-3: 7.3b R8B-2: 8.2b R9C-0: 9.0c that means the current ebuild in portage (9c-r1) is going to not play well with the new version scheme ... i'd suggest just deleting all the ebuilds and starting over with the new schema
I'm getting an error while trying to install erlang-9c and erlang-9c-r1. The error is triggered when all compilation are done and install is begining, I'll past the tail of stdout with error message here: make[2]: Leaving directory `/var/tmp/portage/erlang-9c/work/otp_src_R9B-1/erts/boot/src' make[1]: Leaving directory `/var/tmp/portage/erlang-9c/work/otp_src_R9B-1/erts/boot/src' cd /var/tmp/portage/erlang-9c/image//usr/lib/erlang && ./Install -minimal /var/tmp/portage/erlang-9c/image//usr/lib/erlang /bin/sh: line 1: ./Install: No such file or directory make: *** [install.Install] Error 127 !!! ERROR: dev-lang/erlang-9c failed. !!! Function src_install, Line 31, Exitcode 2 !!! (no error message)
do not post unrelated bug reports to this bug
Hi guys. First a shorter one. Frederico: you may want to try 9c-r1 once again. The -r1 has fixed the problem you reported and recently had a fix for sandbox violation added, which you probably encountered when you were trying -r1 earlier. SpanKY: Well, I am aware of erlang naming scheme for a while now, and what I can say - there is a problem :). For one handling of trailing letters by portage is quite weird: thus for example 9.1c will be considered older than 9c and your proposed scheme won't work. In fact the only reasonable working versioning that was suggested (and it was discussed before a few times) involves completely getting read of letters. Like going 9b => 9.2, 9c => 9.3. This should solve the R9B1 problem (due to which numbering shifted and B1 became 9c) - such version would become 9.2.1. But what will we do if erlang people decide to release something like 9.1C? Are we guaranteed to not encounter this? Another issue is compatibility. There are few apps that deend on erlang, therefore I would rather defer the versioning scheme change. 10x versions would allow to do this cleanely without having to do a complete renaming. I have asked on the -dev and few responses from erlang users seemed to indicate willingness to live with confused versioning util 10x gets released, in order to avoid drastic renaming. So, now with 9c out and our versions only one letter away we have the following options: 1. I add R9C as 9d to make sure it is the latest one. 2. Add it as 9c-r2. Well, this is a new version, so this would be a breach of policy, but on the other hand, this *is* 9C. 3. Add it as 9c-r2 and remove all other 9c ebuilds. All is well and corresponding now in the tree, but this screws the stable version, unless I add 9c as stable immediately, which is bad. Another approach would be to add it as 9c-r2 and remove all previous when -r2 becomes stable. However I would rather have versions <9c removed before - updates are for the purpose after all. All in all I am smewhere in between options 1 and 2.. Claes: you were active on previous erlang bugs, what would be your opinion? George
What about skipping the weird naming scheme erlang has. The R9C type of names are actually an ancient naming scheme used in a *by now since long) retired IBM system used internally at ericsson to maintain the sourcecode for the AXE telephone stations. However, each release of erlang has a number of components, the kernel component is the emulator itself, the code the executes the erlang virtual machine. This is called "erts", Erlang Runtime System. - erts has a new version number in all erlang releases, this will always be the case since software upgrade (uninterupted) doesn't work otherwise. - erts has a normal naming/numbering scheme current version is 5.3 - the erts version is the number displayed by the shell when the system starts # erl Erlang (BEAM) emulator version 5.3 [source] [hipe] Eshell V5.3 (abort with ^G) 1> - the erts version is also returned by the built in function 1> erlang:system_info(system_version). "Erlang (BEAM) emulator version 5.3 [source] [hipe]\n" Just a suggestion to get away from the weird R naming scheme erlang uses.
Well I just added a recommendation to the naming convention on 30364 before seeing this bug. Essentially: ignore the first R and then convert the subsequent letters to numbers where R8B-0 = erlang-8.2.0, R8B-1 = erlang-8.2.1, R9C-0 = erlang-9.3.0 ...etc. where A=1, B=2,...
ive just added erlang-9c-r2 to portage, could you guys try it out ?
This 9c-r2 emerges fine for me. Furthermore I'm able to emerge and run wings with it as well. So with that noted limited scope, it works for me! :)
ok, 9c-r2 is now stable, thanks everyone