first direct responce by Claes

erlang-9c.let1 (text/plain), 7.59 KB, created by George Shapovalov (RETIRED) on 2003-06-13 21:54:41 UTC

From [e-mail] Mon May 12 16:06:37 2003
Received: from earth-ox.its.caltech.edu (SteeleMR-loadb-NAT-49.caltech.edu [131.215.49.69])
	by chamber.cco.caltech.edu (8.12.9/8.12.9) with ESMTP id h4CNBbrb023342
	for <[e-mail]>; Mon, 12 May 2003 16:11:39 -0700 (PDT)
Received: by earth-ox.its.caltech.edu (Postfix, from userid 60008)
	id E46AD20B7EA; Mon, 12 May 2003 16:07:15 -0700 (PDT)
X-Original-To: [e-mail]
Received: from earth-dog (earth-dog [192.168.1.3])
	by earth-ox-postvirus (Postfix) with ESMTP id 75D3120B893
	for <[e-mail]>; Mon, 12 May 2003 16:07:15 -0700 (PDT)
Received: from water-ox ([192.168.1.10])
	by earth-dog (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 12 May 2003 16:07:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by water-ox.its.caltech.edu (Postfix) with ESMTP id C09E926AC38
	for <[e-mail]>; Mon, 12 May 2003 16:07:14 -0700 (PDT)
Received: from water-ox.its.caltech.edu ([127.0.0.1])
 by localhost (water-ox [127.0.0.1]) (amavisd-new, port 33327) with ESMTP
 id 08481-05 for <[e-mail]>;
 Mon, 12 May 2003 16:07:03 -0700 (PDT)
Received: from gentoo.org (mail.gentoo.org [204.126.2.42])
	by water-ox.its.caltech.edu (Postfix) with SMTP id 4EAD126AC46
	for <[e-mail]>; Mon, 12 May 2003 16:06:40 -0700 (PDT)
Received: (qmail 345 invoked by alias); 12 May 2003 23:06:39 -0000
Delivered-To: [e-mail]
Received: (qmail 4829 invoked from network); 12 May 2003 23:06:39 -0000
Received: from unknown (HELO mailb.telia.com) (194.22.194.6)
  by mail.gentoo.org with SMTP; 12 May 2003 23:06:39 -0000
Received: from gnejs.hyber.org (h90n1fls32o899.telia.com [213.67.177.90])
	by mailb.telia.com (8.12.9/8.12.9) with ESMTP id h4CN6c64010641
	for <[e-mail]>; Tue, 13 May 2003 01:06:38 +0200 (CEST)
X-Original-Recipient: <[e-mail]>
Received: (from klacke@localhost)
	by gnejs.hyber.org (8.11.6/8.11.6) id h4CN6bU15662
	for [e-mail]; Tue, 13 May 2003 01:06:37 +0200
Date: Tue, 13 May 2003 01:06:37 +0200
From: Claes Wikstrom <[e-mail]>
To: [e-mail]
Subject: [[e-mail]: Re: [Bug 20625] New release of erlang which can be properley ebuilt]
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain;
  charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Spam-Status: No, hits=-10.2 tagged_above=-100000.0 required=5.0
 tests=QUOTED_EMAIL_TEXT, QUOTE_TWICE_1, USER_AGENT_MUTT
X-Spam-Level: 
Content-Length: 5126
X-UID: 11812
Status: R 
X-Status: N
X-KMail-EncryptionState:  
X-KMail-SignatureState:  



> Nice to see developer of the package here! Not that often happens :).


I'm still almost extatic over the correctness of
the portage approach. 


> 
> > 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.
> 

As I said (or tried too) the version nums of the erlang
kit is bizzare.  The B can change, it seldom does, but R8A preceeds
R8B ... and so forth

So, R8A-0 <  R8B-0 and also
    R8A-1 <  R8B-0

Usually the releases are numbered as R8B-0 < R8B-1 < R8B-2 < R9B-0



> > 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.


Ok, will retry. I suspected I was too fast to try ...


> 
> 
> > 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 :(.


I emerged without sandbox. My system is in perfect shape. :-)
As for sandbox or not, that should be the error I have (I think)
sandboxes come into play at 

# ebuild qmerge 

Or ???




As for /dev/pts 

# grep -i 'pt[ys]' /usr/src/linux/.config
CONFIG_IP_NF_TARGET_IPV4OPTSSTRIP=m
# CONFIG_UNIX98_PTYS is not set
# CONFIG_DEVPTS_FS is not set



> 
> > # 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)..


I though that maybe (ebuild install) did something extremely funky
whith pty's in combination with chroot that I didn't understand 
in order to catch writes outside ${D} 
(Not that I have any idea about how though)

I've googled a bit for similar errors, and indeed it's does seem rare.


> Quite strange I must say. Never met this problem before...
> 

I debugged further, and well ... It's still unclear to me
wether there is something wrong with the erlang Makefiles,
my box, or the ebuild install tool (which is the one that complains)

The /dev/pty errors are still there,
If I do

# ebuild $f unpack
# ebuild $f compile
# ebuild $f install

It did some experiments with the ptys, The pty that fail are
owned by me (since the xterm where I su'ed was created by user=klacke)
Tried to run in xterm started by root, so that the slave end of the pty
should be owned by root too. No avail.

Even tried to explicitly chmod the goddamn pty :-;


Anyway, the really funky stuff is that it does indeed work
when I redirect the output to a file, whenever the output
goes to the tty, it failes with ACCESS VIOLATION.
Could it be someone (??) who writes some bizzare ctl char ??
I'm clueless.

Who checks the access ??? I tried to strace -ff the ebuild install
but that doesn't seem to be the way to debug this ... ehhhum 
lot's of files.



Some other stuff:


1./bin/install

I don't know wether this is a new (mis)feature of /bin/install or
not. I've never seen it before anyway. The install log (if I
tee the ebuild command to a file) contains a couple of errors on
the form:

/bin/install: will not overwrite just-created `/var/tmp/portage/erlang-9c/image/
/usr/lib/erlang/lib/snmp-3.3.8/mibs/SNMP-COMMUNITY-MIB.mib' with `SNMP-COMMUNITY
-MIB.mib'



I've never seen that before. Anyway, install exit /= 0 and the 
remainder of the install commands for that subtarget fail.
All in all, the install isn't good. There are quite a lot of
files that don't get installed due to this.
Keep the ~x86 mask


The hard fix is to figure out why the Makefiles tries to write
the same file twice, the easy fix is to add a '-' in front of the
failing install commands. The erlang Makefiles are  .. well quite
complex.


# ebuild /usr/portage/dev-lang/erlang/erlang-9c.ebuild install > /tmp/p

Shows nicely where this happens (on stderr)




2. patches. Do you want patches for this sort of behaviour.
   I will ofcource send patches to the erlang maintainers at
   ericsson as well, but their release cycles are a bit slow.



Cheers


/klacke


-- 
Claes Wikstrom                        -- Caps lock is nowhere and
http://www.hyber.org                  -- everything is under control