[gentoo-amd64] scons build failure

[gentoo-amd64] scons build failure

[Mark Knecht]

Anything I should try to do about this?

Thanks,
Mark

Saving to: `/usr/portage/distfiles/scons-1.0.0.tar.gz'

100%[======================================>] 541,330      682K/s   in 0.8s

2008-10-20 18:18:02 (682 KB/s) -
`/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:

 * 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).
lightning ~ #

Re: [gentoo-amd64] scons build failure

[Justin]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Mark Knecht schrieb:
> Anything I should try to do about this?
>
> Thanks,
> Mark
>
> Saving to: `/usr/portage/distfiles/scons-1.0.0.tar.gz'
>
> 100%[======================================>] 541,330      682K/s   in 0.8s
>
> 2008-10-20 18:18:02 (682 KB/s) -
> `/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:
>
>  * 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).
> lightning ~ #
>
>   
On my system it works. Do you have enough space in /var/tmp/portage?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-amd64] Re: scons build failure

[Duncan]

"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

Re: [gentoo-amd64] scons build failure

[Mark Knecht]

On Tue, Oct 21, 2008 at 12:21 AM, Justin <justin@j-schmitz.net> wrote:
> Mark Knecht schrieb:
>> Anything I should try to do about this?
>>
>> Thanks,
>> Mark
>>
>> Saving to: `/usr/portage/distfiles/scons-1.0.0.tar.gz'
>>
>> 100%[======================================>] 541,330      682K/s   in 0.8s
>>
>> 2008-10-20 18:18:02 (682 KB/s) -
>> `/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:
>>
>>  * 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).
>> lightning ~ #
>>
>>
> On my system it works. Do you have enough space in /var/tmp/portage?
>
>
I think so. Seems to be about 2GB.

lightning ~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              9614148   6742592   2383180  74% /
udev                     10240       184     10056   2% /dev
/dev/sda6              3850292    777652   2877052  22% /usr/src
/dev/sda8             14428928  11630740   2065224  85% /home
/dev/sda13            48070472  33619600  12008996  74% /mnt/NewMusic
shm                     508016         0    508016   0% /dev/shm
/dev/sda5             38456308  22950852  13551956  63% /home/mark/backups
lightning ~ #

Answering Duncan's question about portage versions I'm a bit behind:

lightning ~ # eix -Ic portage
[I] app-portage/portage-utils (0.1.29@06/28/08): small and fast
portage helper tools written in C
[I] sys-apps/portage (2.1.4.5@10/14/08): Portage is the package
management and distribution system for Gentoo
Found 2 matches.
lightning ~ #

How would I put in the debug echos? I know nothing of this stuff.

Probably before I do that I should at least update portage.

Note also, in case it's important, that I'm somewhat concerned about
python on this machine. I've been getting some strange messages about
locales that I don't understand. Probably they are unrelated to this
problem but better to disclose it now as they are the only ongoing
problem I've got that I've not found a solution for. They show up when
running something like layman to do an overlay update:

lightning ~ # layman -s pro-audio
* Overlay "rostov" is missing a "description" entry!
* Overlay "rostov" is missing a "description" entry!
* Overlay "rostov" is missing a "description" entry!
* Overlay "rostov" is missing a "description" entry!
* Running command "/usr/bin/svn update "/usr/portage/local/layman/pro-audio""...
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US
svn: warning: please check that your locale name is correct
At revision 1344.
*
* Success:
* ------
*
* Successfully synchronized overlay "pro-audio".
lightning ~ #

Here's my /etc/locale.gen file

lightning ~ # cat /etc/locale.gen
#en_US ISO-8859-1
en_US.UTF-8 UTF-8
lightning ~ #

Note that I used to have the ISO-8859 included but after recent
updates CUPS stopped printing from computers across the network. I had
to remove it to allow my family to print.

Again, probably not related but better to get this out there so we can
disregard it.

Thanks all,
Mark

Re: [gentoo-amd64] scons build failure

[Mark Knecht]

All fixed as of this evening. Apparently something got fixed in portage today.

Thanks!

Over and out,
Mark

On Tue, Oct 21, 2008 at 5:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Tue, Oct 21, 2008 at 12:21 AM, Justin <justin@j-schmitz.net> wrote:
>> Mark Knecht schrieb:
>>> Anything I should try to do about this?
>>>
>>> Thanks,
>>> Mark
>>>
>>> Saving to: `/usr/portage/distfiles/scons-1.0.0.tar.gz'
>>>
>>> 100%[======================================>] 541,330      682K/s   in 0.8s
>>>
>>> 2008-10-20 18:18:02 (682 KB/s) -
>>> `/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:
>>>
>>>  * 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).
>>> lightning ~ #
>>>
>>>
>> On my system it works. Do you have enough space in /var/tmp/portage?
>>
>>
> I think so. Seems to be about 2GB.
>
> lightning ~ # df
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/sda2              9614148   6742592   2383180  74% /
> udev                     10240       184     10056   2% /dev
> /dev/sda6              3850292    777652   2877052  22% /usr/src
> /dev/sda8             14428928  11630740   2065224  85% /home
> /dev/sda13            48070472  33619600  12008996  74% /mnt/NewMusic
> shm                     508016         0    508016   0% /dev/shm
> /dev/sda5             38456308  22950852  13551956  63% /home/mark/backups
> lightning ~ #
>
> Answering Duncan's question about portage versions I'm a bit behind:
>
> lightning ~ # eix -Ic portage
> [I] app-portage/portage-utils (0.1.29@06/28/08): small and fast
> portage helper tools written in C
> [I] sys-apps/portage (2.1.4.5@10/14/08): Portage is the package
> management and distribution system for Gentoo
> Found 2 matches.
> lightning ~ #
>
> How would I put in the debug echos? I know nothing of this stuff.
>
> Probably before I do that I should at least update portage.
>
> Note also, in case it's important, that I'm somewhat concerned about
> python on this machine. I've been getting some strange messages about
> locales that I don't understand. Probably they are unrelated to this
> problem but better to disclose it now as they are the only ongoing
> problem I've got that I've not found a solution for. They show up when
> running something like layman to do an overlay update:
>
> lightning ~ # layman -s pro-audio
> * Overlay "rostov" is missing a "description" entry!
> * Overlay "rostov" is missing a "description" entry!
> * Overlay "rostov" is missing a "description" entry!
> * Overlay "rostov" is missing a "description" entry!
> * Running command "/usr/bin/svn update "/usr/portage/local/layman/pro-audio""...
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LANG is en_US
> svn: warning: please check that your locale name is correct
> At revision 1344.
> *
> * Success:
> * ------
> *
> * Successfully synchronized overlay "pro-audio".
> lightning ~ #
>
> Here's my /etc/locale.gen file
>
> lightning ~ # cat /etc/locale.gen
> #en_US ISO-8859-1
> en_US.UTF-8 UTF-8
> lightning ~ #
>
> Note that I used to have the ISO-8859 included but after recent
> updates CUPS stopped printing from computers across the network. I had
> to remove it to allow my family to print.
>
> Again, probably not related but better to get this out there so we can
> disregard it.
>
> Thanks all,
> Mark
>