Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 390571

Summary: dev-perl/CDDB_get 2.27 - environment: line 345: pushd: /var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8: No such file or directory
Product: Portage Development Reporter: knoeck
Component: CoreAssignee: Gentoo Quality Assurance Team <qa>
Status: RESOLVED CANTFIX    
Severity: normal CC: perl, tove
Priority: Normal    
Version: 2.1   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Output of 'emerge --info' on affected system.
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment

Description knoeck 2011-11-14 20:29:39 UTC
When I emerge CDDB_get there is a shell script error which causes the install to fail.  Emerge runs to completion normally but the package is not installed properly.  

Reproducible: Always

Steps to Reproduce:
1.  emerge -v CDDB_get
2.
3.
Actual Results:  
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 345: pushd: /var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8: No such file or directory

Expected Results:  
I expect the install to complete normally.  

# emerge -v  CDDB_get

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-perl/CDDB_get-2.27  0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-perl/CDDB_get-2.27
 * CDDB_get-2.27.tar.gz RMD160 SHA1 SHA256 size ;-) ...                                                           [ ok ]
>>> Unpacking source...
>>> Unpacking CDDB_get-2.27.tar.gz to /var/tmp/portage/dev-perl/CDDB_get-2.27/work
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 345: pushd: /var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8: No such file or directory
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 385: popd: directory stack empty
find: `/var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8': No such file or directory
>>> Source unpacked in /var/tmp/portage/dev-perl/CDDB_get-2.27/work
>>> Compiling source in /var/tmp/portage/dev-perl/CDDB_get-2.27/work ...
 * No Make or Build file detected...
>>> Source compiled.
>>> Test phase [not enabled]: dev-perl/CDDB_get-2.27

>>> Install CDDB_get-2.27 into /var/tmp/portage/dev-perl/CDDB_get-2.27/image/ category dev-perl
>>> Completed installing CDDB_get-2.27 into /var/tmp/portage/dev-perl/CDDB_get-2.27/image/


>>> Installing (1 of 1) dev-perl/CDDB_get-2.27
 * checking 0 files for package collisions
>>> Merging dev-perl/CDDB_get-2.27 to /
>>> Safely unmerging already-installed instance...
No package files given... Grabbing a set.
>>> Regenerating /etc/ld.so.cache...
>>> Original instance of package unmerged safely.
>>> dev-perl/CDDB_get-2.27 merged.
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2011-11-15 15:45:42 UTC
Looks like something polluted the environment. :)

Could you attach the environment file, please?
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2011-11-15 15:48:55 UTC
Also, please post your `emerge --info' output. Looking for anything with version 3.2.8, I guess the most likely candidate for a recent upgrade was sys-process/procps-3.2.8_p11, which does set the S variable to ${WORKDIR}/${PN}-${MY_PV}.
Comment 3 knoeck 2011-11-17 05:44:20 UTC
Created attachment 292849 [details]
Output of 'emerge --info' on affected system.

I have attached the output of 'emerge --info' as a file.  There is no file /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment on my system.  Is it a temporary file that gets removed after emerge completes?  How can I capture it?
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2011-11-17 16:15:59 UTC
(In reply to comment #3)
> Created attachment 292849 [details]
> Output of 'emerge --info' on affected system.
> 
> I have attached the output of 'emerge --info' as a file.  There is no file
> /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment on my system.  Is it a
> temporary file that gets removed after emerge completes?  How can I capture it?

It's created while the package is being compiled. It's left along with all the work files when emerge fails, so it should be there somewhere.
Comment 5 knoeck 2011-11-17 20:06:45 UTC
Created attachment 292943 [details]
/var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment

Here is the environment file, as an attachment.  

emerge is not trapping the shell script error so it completes normally, cleans up after itself, and remove /var/tmp/portage/dev-perl/CDDB_get-2.27/, exiting with a return code of 0.  I had to run ebuild manually through the unpack phase to get this file.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2011-11-18 05:14:58 UTC
Looks like this time the environment was not polluted.
Comment 7 Zac Medico gentoo-dev 2011-11-18 05:40:45 UTC
Since the pushed failure occurs during src_unpack, base_src_unpack from base.eclass (not a portage internal) seems a likely candidate:

base_src_unpack () 
{ 
    debug-print-function $FUNCNAME "$@";
    pushd "${WORKDIR}" > /dev/null;
    [[ -n "${A}" ]] && unpack ${A};
    has src_prepare ${BASE_EXPF} || base_src_prepare;
    popd > /dev/null
}
Comment 8 SpanKY gentoo-dev 2011-11-18 19:20:45 UTC
i don't think base-system has ever touched base.eclass.  sending to @MAINTAINER listed in it ...
Comment 9 Torsten Veller (RETIRED) gentoo-dev 2011-11-19 07:35:41 UTC
I guess it is caused by:
| declare -x MODULE_VERSION="3.2.8"

Where do these variables come from?

MODULEPATH="/usr/local/Modules/versions:/usr/local/Modules/\$MODULE_VERSION/modulefiles:/usr/local/Modules/modulefiles"
MODULESHOME="/usr/local/Modules/3.2.8"
declare -x MODULE_VERSION="3.2.8"
declare -x MODULE_VERSION_STACK="3.2.8"
Comment 10 knoeck 2011-11-20 18:44:15 UTC
Those variables come from my environment.  I have program called Modules installed which sets them.  (http://modules.sourceforge.net/)
Comment 11 Torsten Veller (RETIRED) gentoo-dev 2011-11-22 19:19:25 UTC
Anything we should do to prevent the collision of the perl-module.eclass variable MODULE_VERSION and the Modules env var MODULE_VERSION?
Comment 12 Andreas K. Hüttel archtester gentoo-dev 2014-10-11 08:56:07 UTC
(In reply to Torsten Veller (RETIRED) from comment #11)
> Anything we should do to prevent the collision of the perl-module.eclass
> variable MODULE_VERSION and the Modules env var MODULE_VERSION?

Don't think we can do much here.