Summary: | cat/pkg - /var/tmp/portage/._portage_reinstall_.$RANDOM/bin/ebuild-helpers/$RANDOM_HELPER: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Casper Ti. Vector <CasperVector> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | esigra, gentoo, jaak, sci-mathematics, zerochaos |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=722748 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Casper Ti. Vector
2013-03-15 14:59:42 UTC
This seems to be a wider problem of temporary filenames generated by '/usr/lib64/portage/pym/portage/package/ebuild/doebuild.py' (in method '_prepare_self_update') leaking into installed scripts. Pretty much all cases I've seen relate to 'sed'… In my case, I noticed this due to random breakage with 'libtool'. The weird thing is that I've tried tracking down (grep -r) all instances of this leakage. Manually corrected all of them. Rebuilt the system (emerge -eqv --keep-going system) and the problem keeps coming back *in the same places* (only the 6 random characters picked by 'tempfile.mkdtemp' keep changing). Here's the grep output on a broken system: ----- KO ----- # grep -r _portage_reinstall_ /etc /var {/usr,}/{*bin,lib*} /usr/bin/libtoolize:: ${SED="/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed"} /usr/bin/libtool:SED="/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed" Binary file /usr/bin/emacs-24 matches /usr/bin/mk_cmds:SED=/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed /usr/lib/portage/pym/portage/package/ebuild/doebuild.py: "", "._portage_reinstall_.", build_prefix) Binary file /usr/lib/portage/pym/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib/portage/pym/portage/package/ebuild/doebuild.pyc matches /usr/lib/perl5/5.12.4/x86_64-linux/CORE/config.h:#define LOC_SED "/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed" /**/ /usr/lib/perl5/5.12.4/x86_64-linux/Config_heavy.pl:full_sed='/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed' /usr/lib64/portage/pym/portage/package/ebuild/doebuild.py: "", "._portage_reinstall_.", build_prefix) Binary file /usr/lib64/portage/pym/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib64/portage/pym/portage/package/ebuild/doebuild.pyc matches /usr/lib64/perl5/5.12.4/x86_64-linux/CORE/config.h:#define LOC_SED "/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed" /**/ /usr/lib64/perl5/5.12.4/x86_64-linux/Config_heavy.pl:full_sed='/var/tmp/portage/._portage_reinstall_.3FJgBO/bin/ebuild-helpers/sed' ----- KO ----- The same command on a sane machine gives the following output: ----- OK ----- # grep -r _portage_reinstall_ /etc /var {/usr,}/{*bin,lib*} Binary file /usr/bin/emacs-24 matches /usr/lib/portage/pym/portage/package/ebuild/doebuild.py: "", "._portage_reinstall_.", build_prefix) Binary file /usr/lib/portage/pym/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib/portage/pym/portage/package/ebuild/doebuild.pyc matches Binary file /usr/lib/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyo matches Binary file /usr/lib/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyc matches Binary file /usr/lib/python2.7/site-packages/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib/python2.7/site-packages/portage/package/ebuild/doebuild.pyc matches /usr/lib64/portage/pym/portage/package/ebuild/doebuild.py: "", "._portage_reinstall_.", build_prefix) Binary file /usr/lib64/portage/pym/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib64/portage/pym/portage/package/ebuild/doebuild.pyc matches Binary file /usr/lib64/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyo matches Binary file /usr/lib64/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyc matches Binary file /usr/lib64/python2.7/site-packages/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib64/python2.7/site-packages/portage/package/ebuild/doebuild.pyc matches ----- OK ----- Unfortunately, I don't quite have the time (or the portage chops) to find the root cause, but it's a pretty annoying issue… (-; I'm not sure if this is due to changes in portage, or if this may have worked even with the older versions, but doing "emerge <EFFECTED PKG>" seems to resolve the issue. [For good measure, I also deleted all the cached python code for portage (.pyc and .pyo files) before trying this to make sure any old cruft is gone…] Same issue, portage 2.2.1 and 2.2.7: this is a major issue for me, it's killing my autobuilds. Somewhere, we are losing a race, badly. Nu portage-2.2.7 # grep -r _portage_reinstall_ /etc {/usr,}/{*bin,lib*} Binary file /usr/bin/lynx matches /usr/bin/prxs:my $installer = q(/var/tmp/portage/._portage_reinstall_.iobh1y/bin/ebuild-helpers/xattr/install -c); /usr/lib/icu/51.1/pkgdata.inc:INSTALL_CMD=/var/tmp/portage/._portage_reinstall_.cde5yw/bin/ebuild-helpers/xattr/install -c /usr/lib/ruby/1.9.1/i686-linux/rbconfig.rb: CONFIG["INSTALL"] = '/var/tmp/portage/._portage_reinstall_.cde5yw/bin/ebuild-helpers/xattr/install -c' /usr/lib/python3.2/config-3.2/Makefile:INSTALL= /var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c Binary file /usr/lib/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyc matches Binary file /usr/lib/python3.2/site-packages/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyo matches Binary file /usr/lib/python2.7/_sysconfigdata.pyo matches Binary file /usr/lib/python2.7/site-packages/portage/package/ebuild/doebuild.pyo matches Binary file /usr/lib/python2.7/site-packages/portage/package/ebuild/doebuild.pyc matches /usr/lib/python2.7/config/Makefile:INSTALL= /var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c Binary file /usr/lib/python2.7/_sysconfigdata.pyc matches /usr/lib/python2.7/_sysconfigdata.py: 'INSTALL': '/var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c', /usr/lib/python2.7/_sysconfigdata.py: 'INSTALL_DATA': '/var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c -m 644', /usr/lib/python2.7/_sysconfigdata.py: 'INSTALL_PROGRAM': '/var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c', /usr/lib/python2.7/_sysconfigdata.py: 'INSTALL_SCRIPT': '/var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c', /usr/lib/python2.7/_sysconfigdata.py: 'INSTALL_SHARED': '/var/tmp/portage/._portage_reinstall_.weov16/bin/ebuild-helpers/xattr/install -c -m 555', Binary file /usr/lib/portage/pym/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyo matches Binary file /usr/lib/portage/pym/portage/package/ebuild/__pycache__/doebuild.cpython-32.pyc matches /usr/lib/portage/pym/portage/package/ebuild/doebuild.py: "", "._portage_reinstall_.", build_prefix) Nu portage-2.2.7 # possible candidates for revert: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=458ce208ed25f2d17666926585e14da6166eb9d7 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d3f704a425a50b5cfa997a25866929b30f1b7d0f Any progress ? Emerging dev-db/postgis is failing consistently for me : /var/tmp/portage/._portage_reinstall_.zru70k/bin/ebuild-helpers/xattr/install: Command not found Tried portage-2.2.8-r1 and 2.2.14, as well as reemerging coreutils. I would consider these issues as defects of the packages that hardcode paths to things like 'install' and 'sed' at build time. They should be using PATH at runtime. (In reply to Vincent de Phily from comment #5) > Any progress ? Emerging dev-db/postgis is failing consistently for me : You can mitigate these kinds of issues in the future if you upgrade sys-apps/portage by itself, since the helpers are only in a temporary location when portage is upgrading itself. However, I suggest that you file bugs for the defective packages that fail to use PATH to locate binaries. looks like we need bugs for at least: net-ftp/proftpd www-client/lynx dev-lang/python (both 2.7 and 3.2 definitely have this issue) dev-lang/R sys-devel/libtool dev-lang/perl app-editors/emacs Is there any chance you would consider letting portage upgrade itself separately like it used to? We will be fixing these kinds of things forever if not, and it appears very widespread to me... For some reason, I just got this on an arm system during the install phase of sys-devel/binutils-2.25.1-r1 with the latter trying to use /var/tmp/portage/._portage_reinstall_.$RANDOM/bin/ebuild-helpers/xattr/install . Temporarily symlinked this to /usr/bin/install to work around the issue. (In reply to Jaak Ristioja from comment #9) File a new bug please (see bug 574710 for example). (In reply to Rick Farina (Zero_Chaos) from comment #8) > Is there any chance you would consider letting portage upgrade itself > separately like it used to? No, because the self re-exec shenanigans are too error prone. > We will be fixing these kinds of things forever > if not, and it appears very widespread to me... They're valid bugs. Consider when something moves from /usr/bin to /bin or /sbin or something. They should use PATH at runtime. |