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: | Core | Assignee: | 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
Looks like something polluted the environment. :) Could you attach the environment file, please? /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment 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}. 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?
(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. 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.
Looks like this time the environment was not polluted. 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 } i don't think base-system has ever touched base.eclass. sending to @MAINTAINER listed in it ... 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" Those variables come from my environment. I have program called Modules installed which sets them. (http://modules.sourceforge.net/) Anything we should do to prevent the collision of the perl-module.eclass variable MODULE_VERSION and the Modules env var MODULE_VERSION? (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. |