[gentoo-amd64] Re: scons build failure

[Duncan <1i5t5.duncan@cox.net>]

"Mark Knecht" <markknecht@gmail.com> 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]
> 
> * 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).
> 
>  * 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 
requoted...  Redone above...

As Justin says, it works fine here, but that's not much consolation if 
it's not working for you.

I took a look at the ebuild... and it didn't have its own src_unpack 
function... so I checked the eclasses it inherits.  Viola!  In 
distutils.eclass it does a generic unpack (which appears to have worked, 
it's what outputs that "unpacking <pkg> to <workdir>" bit), then CDs into 
the temporary build dir ($S, $WORKDIR/$P, $P being the package name and 
version, sans revision, according to the ebuild 5 manpage), rms the 
existing ez_setup* scripts and creates its own ez_setup.py script.  

The created ez_setup python script isn't actually executed until the 
compile section, which you never get to.  The problem would therefore 
seem to be either in the call to unpack but after the "unpacking <pkg> to 
<dir>" message, in the CD (which shouldn't normally fail as it's CDing to 
a normal subdir using a standard var, $S, which shouldn't be empty), in 
the rm (which shouldn't fail either), or in the echo creating 
ez_setup.py, which shouldn't fail either!

What version of portage are you running?  FWIW, I'm running the 2.2-rcs, 
specifically portage-2.2_rc12, the latest ~amd64 version as of my sync 
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 
that looked interesting.

What I'd try at this point is editing distutils.eclass, putting in some 
debug echoes to see exactly which line caused it to bail, and what the 
vars it used were set to at the time.  If that's not your thing, it's 
likely time to file a bug.  As I said, I don't see any for scons (fixed 
or not) that look related, so whatever the bug is, it doesn't seem to be 
hitting many people.  It's probably something to do with your config, but 
the question is what?  Unless you can do a bit more debugging yourself, 
filing a bug and having the devs look at it seems to be the next step.

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