| 1 |
"Mark Knecht" <markknecht@×××××.com> posted |
| 2 |
5bdc1c8b0810201820p1ca163b7re5099f72863c0b34@××××××××××.com, excerpted |
| 3 |
below, on Mon, 20 Oct 2008 18:20:48 -0700: |
| 4 |
|
| 5 |
> `/usr/portage/distfiles/scons-1.0.0.tar.gz' saved [541330/541330] |
| 6 |
> |
| 7 |
> * checking ebuild checksums ;-) ... [ ok ] |
| 8 |
> * checking auxfile checksums ;-) ... [ ok ] |
| 9 |
> * checking miscfile checksums ;-) ... [ ok ] |
| 10 |
> * checking scons-1.0.0.tar.gz ;-) ... [ ok ] |
| 11 |
>>>> Unpacking source... |
| 12 |
>>>> Unpacking scons-1.0.0.tar.gz to |
| 13 |
>>>> /var/tmp/portage/dev-util/scons-1.0.0/work Source unpacked. |
| 14 |
> * The ebuild phase 'unpack' has exited unexpectedly. This type |
| 15 |
> * of behavior is known to be triggered by things such as |
| 16 |
> * failed variable assignments (bug #190128) or bad substitution |
| 17 |
> * errors (bug #200313). |
| 18 |
> |
| 19 |
> * Messages for package dev-util/scons-1.0.0: |
| 20 |
|
| 21 |
You know, it'd be nice if they made those messages fit to about 72 chars, |
| 22 |
the standard for posting, so they didn't wrap all wrong when posted and |
| 23 |
requoted... Redone above... |
| 24 |
|
| 25 |
As Justin says, it works fine here, but that's not much consolation if |
| 26 |
it's not working for you. |
| 27 |
|
| 28 |
I took a look at the ebuild... and it didn't have its own src_unpack |
| 29 |
function... so I checked the eclasses it inherits. Viola! In |
| 30 |
distutils.eclass it does a generic unpack (which appears to have worked, |
| 31 |
it's what outputs that "unpacking <pkg> to <workdir>" bit), then CDs into |
| 32 |
the temporary build dir ($S, $WORKDIR/$P, $P being the package name and |
| 33 |
version, sans revision, according to the ebuild 5 manpage), rms the |
| 34 |
existing ez_setup* scripts and creates its own ez_setup.py script. |
| 35 |
|
| 36 |
The created ez_setup python script isn't actually executed until the |
| 37 |
compile section, which you never get to. The problem would therefore |
| 38 |
seem to be either in the call to unpack but after the "unpacking <pkg> to |
| 39 |
<dir>" message, in the CD (which shouldn't normally fail as it's CDing to |
| 40 |
a normal subdir using a standard var, $S, which shouldn't be empty), in |
| 41 |
the rm (which shouldn't fail either), or in the echo creating |
| 42 |
ez_setup.py, which shouldn't fail either! |
| 43 |
|
| 44 |
What version of portage are you running? FWIW, I'm running the 2.2-rcs, |
| 45 |
specifically portage-2.2_rc12, the latest ~amd64 version as of my sync |
| 46 |
less than 24 hours ago. As I said, it works fine. |
| 47 |
|
| 48 |
I just did a quick bug scan for dev-util/scons, and came up with nothing |
| 49 |
that looked interesting. |
| 50 |
|
| 51 |
What I'd try at this point is editing distutils.eclass, putting in some |
| 52 |
debug echoes to see exactly which line caused it to bail, and what the |
| 53 |
vars it used were set to at the time. If that's not your thing, it's |
| 54 |
likely time to file a bug. As I said, I don't see any for scons (fixed |
| 55 |
or not) that look related, so whatever the bug is, it doesn't seem to be |
| 56 |
hitting many people. It's probably something to do with your config, but |
| 57 |
the question is what? Unless you can do a bit more debugging yourself, |
| 58 |
filing a bug and having the devs look at it seems to be the next step. |
| 59 |
|
| 60 |
-- |
| 61 |
Duncan - List replies preferred. No HTML msgs. |
| 62 |
"Every nonfree program has a lord, a master -- |
| 63 |
and if you use the program, he is your master." Richard Stallman |
Archives