When I "emerge -uDv world", the alsa-tools-1.0.6 update will not emerge because it cannot find /var/tmp/portage/alsa-tools-1.0.6/work/alsa-tools-1.0.6/emu10k1. This had not been an issue until recently. I have been running Gentoo since about February of 2004. Reproducible: Always Steps to Reproduce: 1.emerge sync 2.emerge -uDv world 3. Actual Results: >>> emerge (1 of 1) media-sound/alsa-tools-1.0.6 to / >>> md5 src_uri ;-) alsa-tools-1.0.6.tar.bz2 >>> Unpacking source... >>> Unpacking alsa-tools-1.0.6.tar.bz2 to /var/tmp/portage/alsa-tools-1.0.6/work * Applying alsa-tools-1.0.6-gcc34.patch... [ ok ] >>> Source unpacked. * Using GNU config files from /usr/share/libtool * Updating ac3dec/config.sub [ ok ] * Updating ac3dec/config.guess [ ok ] /usr/sbin/ebuild.sh: line 67: cd: /var/tmp/portage/alsa-tools-1.0.6/work/alsa-tools-1.0.6/emu10k1: No such file or directory !!! ERROR: media-sound/alsa-tools-1.0.6 failed. !!! Function econf, Line 364, Exitcode 1 !!! no configure script found Expected Results: alsa-tools should update with the reset of my system alsa-tools-1.0.5 is currently installed
Youu seem to have ALSA_TOOLS=emu10k1 set somewhere (/etc/make.conf perhaps). That is not what you want... you probably wanted to set ALSA_CARDS=emu10k1.
(In reply to comment #1) > Youu seem to have ALSA_TOOLS=emu10k1 set somewhere (/etc/make.conf perhaps). > That is not what you want... you probably wanted to set ALSA_CARDS=emu10k1. > This is indeed the problem... This bug is not invalid: the ebuild should check whether the tool exists, and print an ewarn if it does not (and continue with the emerge process). Letting the emerge die, without clearly informing the user about what is wrong, is not a good thing. I don't remember why I set "ALSA_TOOLS" to "emu10k1" (well, Google tells me yet other people did, but I guess I just misread "as10k1" -maybe they did, too-, which is a correct tool name for alsa-tools), but I still did, and I shouldn't have been bothered by my mistake. This bug should be reopened.
Created attachment 76462 [details, diff] Remove non-existent tool names from ALSA_TOOLS variable (apply to alsa-tools-1.0.10) Here is a patch for the alsa-tools-1.0.10 ebuild... The patch isn't clear, so here is what I've done: - I moved the ALSA_TOOLS related actions from pkg_setup() to to src_unpack() (which is why the patch isn't clear, because there ), as we need to access the source directory, to know if the tool name is valid (the corresponding subdirectory exists or not)... the actions might be split in two parts, but I don't think it's worth it... (and it's good to group those actions) - If the ALSA_TOOLS variable is set by the user, we have the following new actions: ################################################################ # Removes non-existent tool names from our local $ALSA_TOOLS for TOOL_NAME in ${ALSA_TOOLS}; do if [ ! -d "${S}/${TOOL_NAME}" ]; then ALSA_TOOLS=${ALSA_TOOLS/${TOOL_NAME}/} ewarn ewarn "The tool \"${TOOL_NAME}\" in the ALSA_TOOLS environment variable" ewarn "(usually set in /etc/make.conf) does not seem to exist" ewarn "in ${PF}. You should check the tool name syntax" ewarn "or remove it from the ALSA_TOOLS variable." ewarn fi done ################################################################ - After all this, we print the list of tools which will be built: ################################################################ # Prints the tool names which will be built einfo einfo "Tools which will be built: \"${ALSA_TOOLS}\"." einfo ################################################################
