Bug 68746 – alsa-tools-1.0.6 will not emerge because emu10k1 not supported?

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Mark J. Bartlett 2004-10-24 13:56:56 UTC]

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

[Comment 1 Jeremy Huddleston (RETIRED) 2004-10-30 03:37:34 UTC]

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.

[Comment 2 email_deleted_GqKU 2006-01-07 10:26:02 UTC]

(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.

[Comment 3 email_deleted_GqKU 2006-01-07 10:45:32 UTC]

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

################################################################