From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KsCxE-0007P0-7B for garchives@archives.gentoo.org; Tue, 21 Oct 2008 08:51:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0B9EE02B9; Tue, 21 Oct 2008 08:51:02 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 9A755E02B9 for ; Tue, 21 Oct 2008 08:51:02 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KsCxA-0007uh-Jl for gentoo-amd64@lists.gentoo.org; Tue, 21 Oct 2008 08:51:00 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2008 08:51:00 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2008 08:51:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: scons build failure Date: Tue, 21 Oct 2008 08:50:52 +0000 (UTC) Message-ID: References: <5bdc1c8b0810201820p1ca163b7re5099f72863c0b34@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9ce22db9-3c9b-45a0-8117-caaf45b8c2cb X-Archives-Hash: 383bd4ae2fc85e541f6a5855cb087664 "Mark Knecht" posted 5bdc1c8b0810201820p1ca163b7re5099f72863c0b34@mail.gmail.com, excerpted below, on Mon, 20 Oct 2008 18:20:48 -0700: > `/usr/portage/distfiles/scons-1.0.0.tar.gz' saved [541330/541330] >=20 > * checking ebuild checksums ;-) ... [ ok ] > * checking auxfile checksums ;-) ... [ ok ] > * checking miscfile checksums ;-) ... [ ok ] > * checking scons-1.0.0.tar.gz ;-) ... [ ok ] >>>> Unpacking source... >>>> Unpacking scons-1.0.0.tar.gz to >>>> /var/tmp/portage/dev-util/scons-1.0.0/work Source unpacked. > * The ebuild phase 'unpack' has exited unexpectedly. This type > * of behavior is known to be triggered by things such as > * failed variable assignments (bug #190128) or bad substitution > * errors (bug #200313). >=20 > * Messages for package dev-util/scons-1.0.0: You know, it'd be nice if they made those messages fit to about 72 chars, the standard for posting, so they didn't wrap all wrong when posted and=20 requoted... Redone above... As Justin says, it works fine here, but that's not much consolation if=20 it's not working for you. I took a look at the ebuild... and it didn't have its own src_unpack=20 function... so I checked the eclasses it inherits. Viola! In=20 distutils.eclass it does a generic unpack (which appears to have worked,=20 it's what outputs that "unpacking to " bit), then CDs into= =20 the temporary build dir ($S, $WORKDIR/$P, $P being the package name and=20 version, sans revision, according to the ebuild 5 manpage), rms the=20 existing ez_setup* scripts and creates its own ez_setup.py script. =20 The created ez_setup python script isn't actually executed until the=20 compile section, which you never get to. The problem would therefore=20 seem to be either in the call to unpack but after the "unpacking to= =20 " message, in the CD (which shouldn't normally fail as it's CDing to= =20 a normal subdir using a standard var, $S, which shouldn't be empty), in=20 the rm (which shouldn't fail either), or in the echo creating=20 ez_setup.py, which shouldn't fail either! What version of portage are you running? FWIW, I'm running the 2.2-rcs,=20 specifically portage-2.2_rc12, the latest ~amd64 version as of my sync=20 less than 24 hours ago. As I said, it works fine. I just did a quick bug scan for dev-util/scons, and came up with nothing=20 that looked interesting. What I'd try at this point is editing distutils.eclass, putting in some=20 debug echoes to see exactly which line caused it to bail, and what the=20 vars it used were set to at the time. If that's not your thing, it's=20 likely time to file a bug. As I said, I don't see any for scons (fixed=20 or not) that look related, so whatever the bug is, it doesn't seem to be=20 hitting many people. It's probably something to do with your config, but= =20 the question is what? Unless you can do a bit more debugging yourself,=20 filing a bug and having the devs look at it seems to be the next step. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman