FEATURES="-collision-protect" emerge bash ... !!! failed to properly create symlink: !!! /usr/share/info/bashref.info.gz -> .gz !!! [Errno 2] No such file or directory: '/usr/share/info/bashref.info.gz' !!! Failed to move file. !!! /usr/share/info/bashref.info.gz -> .gz emerge /usr/portage/net-ftp/lftp-3.0.7.ebuild ... Traceback (most recent call last): File "/usr/lib/portage/bin//emerge", line 2755, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/lib/portage/bin//emerge", line 1678, in merge retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug) File "/usr/lib/portage/pym/portage.py", line 2779, in doebuild return merge(mysettings["CATEGORY"],mysettings["PF"],mysettings["D"],mysettings["BUILDDIR"]+"/build-info",myroot,mysettings,myebuild=mysettings["EBUILD"]) File "/usr/lib/portage/pym/portage.py", line 2901, in merge return mylink.merge(pkgloc,infloc,myroot,myebuild) File "/usr/lib/portage/pym/portage.py", line 6694, in merge return self.treewalk(mergeroot,myroot,inforoot,myebuild,cleanup=cleanup) File "/usr/lib/portage/pym/portage.py", line 6221, in treewalk if catpkgsplit(p)[0] == self.cat and catpkgsplit(p)[1] == pkgsplit(self.pkg)[0]: TypeError: unsubscriptable object Reproducible: Always Steps to Reproduce: 1. FEATURES="-collision-protect" emerge bash 2. emerge /usr/portage/net-ftp/lftp/lftp-3.0.7.ebuild 3. Actual Results: see details Expected Results: bash emerged successfully !!! Using `which gcc` to gcc locate version, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 20040726 (default-macos-10.3, gcc-3.3, unavailable, 7.5.0 Power Macintosh powerpc) =============================================================== == System uname: 7.5.0 Power Macintosh powerpc macos-20040726 distcc 2.0.1-zeroconf powerpc-apple-darwin7.0 (protocol 1) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.57,sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.6.3,sys-devel/automake-1.8.3 Binutils: ACCEPT_KEYWORDS="macos ppc" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="powerpc-apple-darwin" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/ qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect cvs keepwork" GENTOO_MIRRORS="http://gentoo.osuosl.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="macos berkdb cdr ldap mysql perl python ruby"
i'm on an iBook G4 1Ghz btw, if that helps.
The same thing happens with bash-2.05b-r5. dosym appears to not like parameters which contain dots (.) when executed on osx. I'll attach a patch to fix the ebuild but someone familiar with/working on portage should have a look at fixing dosym.
sorry, that should read bash-3.0-r5.
Created attachment 39086 [details, diff] patched around dosym, added ~macos
dosym: #!/bin/bash # Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-src/portage/bin/dosym,v 1.6 2003/02/22 16:59:08 carpaski Exp $ if [ ${#} -ne 2 ] ; then echo "${0}: two arguments needed" exit 1 fi target="${1}" linkname="${2}" ln -snf "${target}" "${D}${linkname}" ------------- The only thing I can imagine is that MacOS doesn't understand ln -n Could you please try: ln -sfn $HOME/asdf.1.2 $HOME/sdfg.3.4 ls -ld $HOME/sdfg.3.4 rm -f $HOME/sdfg.3.4 and post those results.
pathose@luna ~ $ ln -sfn $HOME/asdf.1.2 $HOME/sdfg.3.4 pathose@luna ~ $ ls -ld $HOME/sdfg.3.4 lrwxr-xr-x 1 pathose pathose 23 28 Sep 14:47 /Users/pathose/sdfg.3.4 -> /Users/pathose/asdf.1.2 pathose@luna ~ $ ls -ld $HOME/sdfg.3.4 ls: /Users/pathose/sdfg.3.4: No such file or directory
Sorry, that last entry is the results of the directory listing after the rm has been issued. Also, from the ln man page: SYNOPSIS ln [-fhinsv] source_file [target_file] ln [-fhinsv] source_file ... target_dir link source_file target_file ... The options are as follows: ... -h If the target_file or target_dir is a symbolic link, do not follow it. This is most useful with the -f option, to replace a symlink which may point to a directory. ... -n Same as -h, for compatibility with other ln implementations.
This depends on bug 67162. Will take a look at it when 67162 has gotten somewhere. Until then, this bug should remain frozen.
