If a user sets the environment variable A, this will cause src_unpack to unpack ${A} during each subsequent emerge, likely crashing the emerge. I assume this also applies to other environment variables / portage phases. Reproducible: Always Steps to Reproduce: export A=3 emerge nano * nano-2.1.7.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking 3 to /var/tmp/portage/app-editors/nano-2.1.7-r1/work * * ERROR: app-editors/nano-2.1.7-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2188: Called unpack '3' * ebuild.sh, line 356: Called die * The specific snippet of code: * [[ ! -s ${srcdir}${x} ]] && die "${x} does not exist" * The die message: * 3 does not exist * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/app-editors/nano-2.1.7-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-editors/nano-2.1.7-r1/temp/environment'. *
*** This bug has been marked as a duplicate of bug 253467 ***
This bug have been fixed a long time ago; how can you still entounter it ? is your portage up to date ? how often do you update ? emerge --info !!!
(In reply to comment #2) > This bug have been fixed a long time ago; how can you still entounter it ? is > your portage up to date ? how often do you update ? > > emerge --info > !!! Portage 2.6.1.13, latest stable. Did you even try the two-line reproduction before insinuating that I'm an out-of-sync moron?
No, i had not, because I knew it was useless. Because I had this bug, and it had been fixed for me. And that after the fix, I updated my portaged, tested back, and confirmed it was fixed for the 2.1 branch. The question is not if I did the test, but, why did the maint marked immediately your bug as dup of an already fixed one. That is the point that disturbed me. And, the reason is that you did not give any detail about your system. Because your report is missing the VITAL ESSENTIAL BASIC information, aka emerge --info, I am allowed to assume anything. A report lacking this base is not a report. Unless you can proove the bug is portage-version independant. I am doing your test now, and I can reproduce it. But this does not mean any thing: http://bugs.gentoo.org/show_bug.cgi?id=253467#c6 states "This is fixed in 2.1.6.5 and 2.2_rc21." . As unstable portage is unstable, I am not surprised API breake again. And I will report it. But, at last, you say you use latest stable portage 2.6.1.13, and I am sorru to say you that in the tree I sync yesterday night, there is no such version, or even close: moon-gen-3 etc # ls /usr/portage/sys-apps/portage/ ChangeLog metadata.xml portage-2.1.6.13.ebuild portage-2.2_rc33.ebuild files portage-2.1.4.5.ebuild portage-2.1.6.4.ebuild Manifest portage-2.1.6.11.ebuild portage-2.1.6.7.ebuild moon-gen-3 etc # I now doubt about your ability to determine the version of portage you are using, and ask again for compleet emerge --info. The only official and systematical way to learn about your portage version, at the same time as your miror URL, and shape of tree ...
I am sorry to say that there is a even a 2.6.1.13 entry in what you pasted. Thank you.
Also, since my bug was marked as as duplicate, the requested emerge --info was already pasted to the 'original'.
