I think I managed to reproduce this with --with-audio="oss win32 esd nas dummy". I got:
checking if you are too dumbing dumb for the dummy... no
checking if you are too dumbing dumb for the dummy... no
....
....
Checked audio modules ... oss win32 esd nas dummy dummy
Detected audio support .. oss win32 esd nas dummy dummy
Looks like a quick workaround is to avoid specifying dummy, since it will always be enabled anyway.
Anybody with proper shell foo care to comment?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, yes, it's twice in the list when you mention dummy in --with-audio. I didn't expect people to do that. I always add dummy to the list to have it as last resort:
if test "x$with_audio" != "x"; then
check_modules="`echo $with_audio|tr , ' '` dummy"
echo "Limiting outputs to build according to your preference: $check_modules"
check_forced=yes
fi
So, if everything fails, you still get a build with dummy output. One can discuss now if that's good or not. One might raise the issue of users specifying --with-audio="oss win32 oss win32 oss" hm, actually I'm not sure if that would cause any trouble trying --with-audio="alsa alsa" ... doesn't seem to cause any trouble.
Well, of course one can add code to configure that filters out duplicates, to keep things polished, but is it necessary/worth it? One might rather focus on the question if dummy should always be implicitly in the list. Comments on that one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you post more details? Such as your configure line.
I can't reproduce this in Cygwin.
The full log file is here http://paste.pocoo.org/show/238966/ , the appropriate configure line is :
tfoerste@n22 ~ $ grep configure /var/log/portage/media-sound:mpg123-1.12.1:20100717-135221.log
./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --with-optimization=0 --with-audio=dummy sdl alsa --with-default-audio=alsa --with-cpu=x86 --enable-network --enable-ipv6
configure: creating ./config.status
>>> Source configured.
I think I managed to reproduce this with --with-audio="oss win32 esd nas dummy". I got:
checking if you are too dumbing dumb for the dummy... no
checking if you are too dumbing dumb for the dummy... no
....
....
Checked audio modules ... oss win32 esd nas dummy dummy
Detected audio support .. oss win32 esd nas dummy dummy
Looks like a quick workaround is to avoid specifying dummy, since it will always be enabled anyway.
Anybody with proper shell foo care to comment?
Well, yes, it's twice in the list when you mention dummy in --with-audio. I didn't expect people to do that. I always add dummy to the list to have it as last resort:
if test "x$with_audio" != "x"; then
check_modules="`echo $with_audio|tr , ' '` dummy"
echo "Limiting outputs to build according to your preference: $check_modules"
check_forced=yes
fi
So, if everything fails, you still get a build with dummy output. One can discuss now if that's good or not. One might raise the issue of users specifying --with-audio="oss win32 oss win32 oss" hm, actually I'm not sure if that would cause any trouble trying --with-audio="alsa alsa" ... doesn't seem to cause any trouble.
Well, of course one can add code to configure that filters out duplicates, to keep things polished, but is it necessary/worth it? One might rather focus on the question if dummy should always be implicitly in the list. Comments on that one?
A Gentoo developer doesn't see a problem : https://bugs.gentoo.org/show_bug.cgi?id=328821
Well, if this is only a cosmetic problem then probabl<y not worth to deal with.
DmD5Td <a href="http://bnvwsdinxped.com/">bnvwsdinxped</a>, [url=http://pwirudncpwwg.com/]pwirudncpwwg[/url], [link=http://goksivxqszhb.com/]goksivxqszhb[/link], http://aqahjsapkzlo.com/
Well, then, there are more serious issues in life.