"Mark Knecht" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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
