Ooookay. Since it seemed that it's /usr/lib/portage/bin/ebuild.sh which is the script that throws all the errors, I decided to do some hacking on it (after backing it up - I'm not
completely insane yet.)
Since the error got thrown at line 1200 tha seemed to be a good place to start:
Code: Select all
<SNIP about 1180 lines>
debug-print "inherit: $1 -> $location"
[ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
#We need to back up the value of DEPEND and RDEPEND to B_DEPEND and B_RDEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
unset B_IUSE B_DEPEND B_RDEPEND B_PDEPEND
[ "${IUSE-unset}" != "unset" ] && B_IUSE="${IUSE}"
[ "${DEPEND-unset}" != "unset" ] && B_DEPEND="${DEPEND}"
[ "${RDEPEND-unset}" != "unset" ] && B_RDEPEND="${RDEPEND}"
[ "${PDEPEND-unset}" != "unset" ] && B_PDEPEND="${PDEPEND}"
unset IUSE DEPEND RDEPEND PDEPEND
#turn on glob expansion
set +f
source "$location" || die "died sourcing $location in inherit()" # <- Line 1200, which is where it dies
#turn off glob expansion
set -f
<SNIP>
Judging from the error message, the problem was obviously that $location was set to NULL, when it should have been set to something meaningful by the time the script got to line 1200. I looked around the script, and did some checking by inserting "echo" commands here and there, to see if $location was correctly assigned. It turned out that everything was okay, just until about line 1200 when $location for some obscure reason lost its value. Changing the script like this, would make it go further:
Code: Select all
debug-print "inherit: $1 -> $location"
[ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
uglyhack=$location # <-- Change number 1
#We need to back up the value of DEPEND and RDEPEND to B_DEPEND and B_RDEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
unset B_IUSE B_DEPEND B_RDEPEND B_PDEPEND
[ "${IUSE-unset}" != "unset" ] && B_IUSE="${IUSE}"
[ "${DEPEND-unset}" != "unset" ] && B_DEPEND="${DEPEND}"
[ "${RDEPEND-unset}" != "unset" ] && B_RDEPEND="${RDEPEND}"
[ "${PDEPEND-unset}" != "unset" ] && B_PDEPEND="${PDEPEND}"
unset IUSE DEPEND RDEPEND PDEPEND
#turn on glob expansion
set +f
location=$uglyhack # <-- Change number 2
source "$location" || die "died sourcing $location in inherit()"
#turn off glob expansion
set -f
Notice that I said "go further", not "run". Now I got another error. After doing some initial checks that end with the "winky smiley" to indicate success. The script told me to "Please specify a valid command" and then proceeded to output a lengthy instruction set for "ebuild". I located the offending error message to almost the very end of the script, and again I started troubleshooting by inserting "echo" commands to get a closer look at what it was doing. The code looked like this:
Code: Select all
for myarg in $*; do
case $myarg in
nofetch)
<SNIP>
prerm|postrm|postinst|config)
<SNIP>
unpack|compile|test|clean|install)
if [ "${SANDBOX_DISABLED="0"}" == "0" ]; then
export SANDBOX_ON="1"
else
export SANDBOX_ON="0"
fi
if [ "$PORTAGE_DEBUG" != "1" ]; then
dyn_${myarg}
#Allow non-zero return codes since they can be caused b$
else
set -x
dyn_${myarg}
#Allow non-zero return codes since they can be caused b$
set +x
fi
export SANDBOX_ON="0"
;;
help|setup|preinst)
<SNIP>
depend)
<SNIP>
*)
export SANDBOX_ON="1"
echo "Please specify a valid command."
echo
dyn_help
exit 1
;;
esac
The whole error was really weird. It would seem that everything in this function went just fine, until the script called it with the "unpack" parameter. (Cleaning for instance worked perfectly.) Then for some bizarre reason it wouldn't recognize the parameter, and default to the "Please specify a valid command" error. I added the following "echo" line in order to see if the values were preserved:
Code: Select all
for myarg in $*; do
echo "crap: "$* $myarg
case $myarg in
AND THE SCRIPT FLIPPIN' RAN!!!
I added NOTHING but a line to print some crap to the screen, and that was the difference between the script recognizing the parameter, and not! If I posted this during the same quarter as april fools day, noone would believe me.
I still haven't tried to actually log in, because I'm rather doubtful as to whether it would work. I can't really see any parallells between hacking an ebuild script and logging on to the system... but then again I don't see why these stupid workarounds of mine should affect the script either. I suppose that in order to log in I'll have to smear myself in chicken blood and run naked 7 times around my house clockwise, at midnight during a full moon while screaming "IA, IA, CTHULHU FHTAGHN!"
