The dev-lang/erlang-9b.ebuild is masked. I assume the reason for this was that it appeared to install stuff (unclear to me which files) outside ${D} Anyway, there's now a new release of erlang that appears to ebuild fine. Did for me anyway Reproducible: Always Steps to Reproduce: 1. 2. 3. Erlang use some strange versioning scheme naming releases to i.e R9B-1 etc. If I name the new ebuild file to i.e. erlang-9b1.ebuild (to replace erlang-9b.ebuild) emerge doesn't like the filename. I named the new file to erlang-9.1.ebuild # diff -u erlang-9b.ebuild erlang-9.1.ebuild --- erlang-9b.ebuild 2003-03-11 22:20:56.000000000 +0100 +++ erlang-9.1.ebuild 2003-05-08 11:54:06.000000000 +0200 @@ -6,12 +6,12 @@ DESCRIPTION="Erlang programming language, runtime environment, and large collection of libraries" HOMEPAGE="http://www.erlang.org/" -SRC_URI="http://www.erlang.org/download/otp_src_R9B-0.tar.gz" -S="${WORKDIR}/otp_src_R9B-0" +SRC_URI="http://www.erlang.org/download/otp_src_R9B-1.tar.gz" +S="${WORKDIR}/otp_src_R9B-1" LICENSE="EPL" SLOT="0" -KEYWORDS="~x86" +KEYWORDS="x86" DEPEND=">=dev-lang/perl-5.6.1 X? ( >=x11-base/xfree-4.2.0-r12 )
Created attachment 11677 [details, diff] erlang ebuild diff
Hi Claes. Thanks for the submission! >The dev-lang/erlang-9b.ebuild is masked. I assume the reason for this was that it >appeared to install stuff (unclear to me which files) outside ${D} Hm, I do not see any indcation of this happening, and the ebuild is only keymasked, not package.mask masked. This just means, that it is in "testing" profile, and should get into stable as soon as it gets anough testing, with which you (and everybody interested in seeing it in "x86") can defintely help ;). Anyway, I processed your submission. I had to change the PV part of te name - 9.1 was considered to be older by portage than 9b. The only reasonable solution I could think of was to mark this version 9c. The alternative would be to make it 9b-r1 and then keep increasing -rX's until R10B or whatever comes along. But I think this is incorrect, as this is really a new version and not some gentoo-specific modification to the same source.. Also looks to me, that 'R' and 'B' are invariant parts of the naming scheme used by erlang developers, then 9c shouldn't cause problems. Moreover I think we will need to just drop this 'b' from PV in future versions, to avoid situations like this one. The ebuild is committed, please test. George
*** Bug 15623 has been marked as a duplicate of this bug. ***
Hi Claes. That message, you answered to, was autogenerated in responce to my posting to the bug on bugzilla ;). Let's keep the conversation here, so that we could trace what was happening, should there be any need later on... > No problem, I'm kindof semi new to gentoo, like it very much > and want the erlang ebuild to be as good as possible. (I'm one > of the original developers of the language) Nice to see developer of the package here! Not that often happens :). > The R part just stands for "Release", it's ancient Ericsson speak for > naming software releases. You could actually ignore that (R) if it > interferes with your naming scheme. What about the 'B'? Is this expected to change, or only the numbers? If only the numbers, than present versioning scheme for ebuild should work - I started incrementing the last letter, as I described above. > and didn't get no new ebuild ... Am I supposed to get it from > some CVS repository or what ?? .. You emerge sync gets the tree from the mirror, and there is some lag, usually within 30-60 min. Just try again later on.. I just checked, the new version is already on mirrors. > open_wr: /dev/pty/s2 > open_wr: /dev/pty/s2 > open_wr: /dev/pty/s2 > open_wr: /dev/pty/s2 > open_wr: /dev/pty/s2 > open_wr: /dev/pty/s2 > > > which doesn't seem that good. What does it mean ? This is strange. I just retested the -9b version, all emerged fine, with sandbox enabled. I suspect some misconfiguration on your system. Do you by chance have both devfs and /dev/pts compiled in in the kernel? Or possibly some permission mismatch? Not really sure what this means :(. > # find / -mount -name '*' > /tmp/before > and a corresponding > # find / -mount -name '*' > /tmp/after > > > after the install, and it doesn't seem as it tries to write > anyting outside /tmp/foo according to diff of the 2 files. Well, /dev/pty/* should correspond to pseudo terminals, so I doubt above would have cought anything related (or related to general device access for that matter).. Quite strange I must say. Never met this problem before... George
*** Bug 21986 has been marked as a duplicate of this bug. ***
Hi Claes. Reopening this bug, since this strange misbehaviour seems to be happening not only with you. Sorry for not getting back to this earlier - I got carried away by the discussion of proper ebuild versioning. Also the fact that you were answering to me directly doe not ease finding what has been said either ;). Could you please reply by adding your comment to this bug, should you have any? As an added bonus this will ease the life of other people, should they get interested in this issue even after the conversation has taken place. So, did you get to any conclusion or at least the idea of what has been happening? I will try looking into this shortly now, that this bug is reopened. Meanwhile I am attaching your emails on this matter, since they may be of interest to Nikl and others. BTW, any idea when R9C is supposed to come out? George
Created attachment 13246 [details] first direct responce by Claes
Created attachment 13247 [details] a followup
Nope, I have no idea. Assuming that you are talking about the strange pty errors I reported. What triggers it, somebody is actully writing there, If some compile program tried to fiddle with, say tcgetatrr() and tcsetattr(), could this trigger this ?? Erlang compile, invokes erl itself (on numerous occasions) and 'erl' sets tty attributes ... ?? Just a theory. I +will try looking into this shortly now, that this bug is reopened. Meanwhile I am +attaching your emails on this matter, since they may be of interest to Nikl and +others. Ok There is one other bug that is related to the install command: I wrote to the erlang patch list: the following: Folks, It appears if as the install command in GNU fileutils behave differently in later releases. The bug in the erlang Makefiles manifests itself in gentoo linux systems which run an install command that is slightly newer than on i.e. rh9.0. Anyway, older install did complain when we tried to install the same file twice. Try for example: # touch foo; install foo foo /tmp This command fails on newer install. See: # install --version install (fileutils) 4.1.11 Written by David MacKenzie. Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # touch foo; install -c foo foo /tmp install: will not overwrite just-created `/tmp/foo' with `foo' # echo $? 1 Thus erlang Makefiles fail to install a number of files: The easiest way to reproduce is to do: # make install > /tmp/stdout Anything that gets written to stderr is an error. I attach a patch. apply as : # cd otp_src_R9B-1; # patch -p0 < /path/to/install.patch
Created attachment 13276 [details, diff] broken /bin/install program fix This patch is for the erlang-9c.ebuild build. It remedies the new strange bahaviour of /bin/install.
Hi Claes. Thanks a lot for the patch! Unfortunately looks like bugzilla does not handle the stress too well either and I am not always receiving notification emails :(. I just noticed your fix.. I combined this patch with the one from #22836. BTW, please submit your patches in the unified format (diff -u), we are trying to standardise on that one. The patch went into the -r1 ebuild, please test. George
Reclosing the bug
