I've found I can't use quickpkg on my amd64-linux install of prefix-portage, but it works OK on my x86-linux and x86-macos installations. For example, using "Portage 2.2.00.8435-prefix (default-prefix/linux/amd64/no-multilib, gcc-4.2.2, unavailable, 2.6.18-4-amd64 x86_64)" $ quickpkg portage Traceback (most recent call last): File "/opt/hwbp/usr/bin/quickpkg", line 199, in <module> from portage import settings ImportError: No module named portage I've been able to work around this by replicating the sys.path adjustment call from the ebuild python script: try: import portage except ImportError: from os import path as osp sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), "pym")) import portage Reproducible: Always
can you post the output of % head `which emerge`
gigantor ~ # head `which emerge` #!/opt/hwbp/usr/bin/python # Copyright Gentoo Foundation 2006 # Portage Emerge bits # $Id: emerge 8297 2007-10-25 20:00:02Z grobian $ try: import _emerge except ImportError: from os import path as osp import sys
your EPREFIX = /opt/hwbp ?
(In reply to comment #3) > your EPREFIX = /opt/hwbp ? > Correct. Portage 2.2.00.8470-prefix (default-prefix/linux/amd64/no-multilib, gcc-4.2.2, unavailable, 2.6.18-4-amd64 x86_64) ================================================================= System uname: 2.6.18-4-amd64 x86_64 Intel(R) Xeon(R) CPU 5140 @ 2.33GHz Timestamp of tree: Fri, 09 Nov 2007 22:02:40 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.5.1-r3 dev-python/pycrypto: 2.0.1-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18.50.0.3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.11-r6 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fno-stack-protector" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/opt/hwbp/usr/portage/distfiles" EPREFIX="/opt/hwbp" FEATURES="collision-protect distlocks metadata-transfer nomultilib nostrip sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_AU.UTF-8" PKGDIR="/opt/hwbp/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/opt/hwbp/var/tmp" PORTDIR="/opt/hwbp/usr/portage" SYNC="svn+http://overlays.gentoo.org/svn/proj/alt/trunk/prefix-overlay" USE="amd64 cracklib d gcj iconv ipv6 midi mudflap ncurses openmp pcre postgres prefix python readline ssl unicode zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Having a look at the amd64 Gentoo Proper install (well, just a stage1 tarball contents to be precise), I can see that the portage python libraries are installed into /usr/lib64/portage/pym $ cat stage1-amd64-2007.0.tar.bz2.CONTENTS | grep "portage\/pym" | head drwxr-xr-x root/root 0 2007-04-16 22:41 ./usr/lib64/portage/pym/ -rw-r--r-- root/root 4074 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_data.pyo -rw-r--r-- root/root 10336 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_exec.py -rw-r--r-- root/root 30908 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_util.pyo -rw-r--r-- root/root 8189 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_locks.pyo -rw-r--r-- root/root 15658 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_dep.pyo -rw-r--r-- root/root 8300 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_versions.py -rw-r--r-- root/root 8542 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_update.pyo -rw-r--r-- root/root 2409 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_const.pyo -rw-r--r-- root/root 21813 2007-04-16 22:41 ./usr/lib64/portage/pym/portage_manifest.py However with Prefix Portage, it puts these into EPREFIX/usr/lib/portage/pym (not lib64). If I create a symlink in EPREFIX/usr/lib64/portage -> EPREFIX/usr/lib/portage this gets quickpkg working without the code I described above. Should prefix-portage be like mainline portage and install into usr/lib64 instead of usr/lib when on amd64?
I think I know what bites you here. baselayout wouldn't create a lib -> lib64 symlink, so it's probably missing. If you would have it, the path would exist, right? Can you check you have or don't have this symlink?
(In reply to comment #6) > I think I know what bites you here. baselayout wouldn't create a lib -> lib64 > symlink, so it's probably missing. If you would have it, the path would exist, > right? > > Can you check you have or don't have this symlink? > I bootstrapped from scratch again yesterday. I do have an EPREFIX/lib -> EPREFIX/lib64 symlink, but EPREFIX/usr/lib and EPREFIX/usr/lib64 have different contents.
ok, I have exactly the same issue now, and .. oh wait ... turbo joy. Not sure any more. I was once told that portage shouldn't install into lib64, since it only installs "noarch" libs (python zut). Anyway, /if/ baselayout had created the proper symlink, this wouldn't be a problem...
As far as I understand, this bug is caused by a bug in baselayout-prefix. It should create a symlink for lib -> lib64 such that this problem does not occur. Multilib is a hell, and I already regret that I ever added it to Prefix.
