Hide Forgot
Description of problem: I am using the secondlife rc from http://release-candidate-secondlife-com.s3.amazonaws.com/SecondLife_i686_1_19_0_0_RELEASECANDIDATE.tar.bz2 In this release the voice should be enabled, but not on my x86_64 box (the voice works on my fc7 i386 box although) Version-Release number of selected component (if applicable): ? How reproducible: Very Steps to Reproduce: 1. When started in a terminal with the oss and esd disabled it gives a alsa error on startup: 2.ALSA lib pcm.c:2106:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so 3. Actual results: no voice in the rc Expected results: voice in rc Additional info:
I also filed in a bug report on: http://jira.secondlife.com/browse/VWR-4585
please run system-config-soundcard and check the test sound. generate logs (/root/scsconfig.log and /root/scsrun.log) and attach them here.
Created attachment 294095 [details] scsconfig.log
Created attachment 294096 [details] scsrun.log
Do you use that "C-Media USB Headphone Set" audio device or would you like to play with integrated sound device? (intel HDA)
I use the C-Media USB Set, it has better sound than the build integrated sound device.
I hope there is some 32bit depandacy packages wich I should install or something like that. The defenitly seems to be something missing in alsa. I can find a /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so tried to symlink it, but it still can find the library
it's from alsa-plugins-pulseaudio-1.0.15-2.fc8.x86_64 - reassigning.
multiarch is our downfall.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
After installing wine-1.1.10-1.fc11.i386 on an x86_64 box, launching a certain exe file results in the error message: "wine: created the configuration directory '/home/fedora/.wine' ALSA lib pcm.c:2162:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so" File /usr/lib/alsa-lib/libasound_module_pcm_pulse.so belongs to package alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386 which is not installed, only the x86_64 version alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.x86_64. After installing alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386, too, the error message goes away. Thus, WINE should clearly pull in alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386 However, even when WINE is installed neither alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.x86_64 nor alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386 are required by any installed package and can be uninstalled without complaint leaving a soundless WINE behind.
Lennart, could you please take this one over. I am not too sure how to address this issue.
This is (In reply to comment #10) So how do we update the versio? That doesn't seem to be an editable field. > This message is a reminder that Fedora 8 is nearing its end of life. > Approximately 30 (thirty) days from now Fedora will stop maintaining > and issuing updates for Fedora 8. It is Fedora's policy to close all > bug reports from releases that are no longer maintained. At that time > this bug will be closed as WONTFIX if it remains open with a Fedora > 'version' of '8'. > > Package Maintainer: If you wish for this bug to remain open because you > plan to fix it in a currently maintained version, simply change the 'version' > to a later Fedora version prior to Fedora 8's end of life. > > Bug Reporter: Thank you for reporting this issue and we are sorry that > we may not be able to fix it before Fedora 8 is end of life. If you > would still like to see this bug fixed and are able to reproduce it > against a later version of Fedora please change the 'version' of this > bug to the applicable version. If you are unable to change the version, > please add a comment here and someone will do it for you. > > Although we aim to fix as many bugs as possible during every release's > lifetime, sometimes those efforts are overtaken by events. Often a > more recent Fedora release includes newer upstream software that fixes > bugs or makes them obsolete. > > The process we are following is described here: > http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is failing in Fedora 10 as well. Please don't close this bug with Fedora 8.
(In reply to comment #14) > This is failing in Fedora 10 as well. So, what is failing exactly? The initial bug report is nonsense, because when you unpack some i686 binary on an x86_64 system, it is very likely that required 32 bit libraries are missing. The situation is very different when you use YUM for installing prebuilt packages from a repository. WINE that I mentioned in comment #11 was installed by means of the package manager. The issue thus is rather a WINE one, or - even more likely - a YUM one, because a 32 bit dependency seems to be resolved incorrectly.
This is actually the same situation as #460188: rpm does not allow 'conditional' dependencies as in "when 32bit libasound is installed 64bit libasound-plugins-pulse should pull in 32bit libasound-plugins-pulse". Hence closing as duplicate. *** This bug has been marked as a duplicate of bug 460188 ***
I still don't get your point: the i386 wine package is responsible of reclaiming required packages of the same architecture at install time. Apparently, this is not the case. After pulling in alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386 manually, sound was working correctly. So, what is so difficult about adding this package to the "Requires" list in wine.spec? RPM should of course be smart enough to pull in the package of the same architecture as that of the package which is scheduled for being installed.
Uh? Why would be having a dep on 32 bit a-p-p make sense for wine? It doesn't need this dependency, unless 64 bit a-p-p is also installed.
Same problem on Fedora 14 - 64bits with Blender alsa-plugins-pulseaudio-1.0.15-2.fc8.x86_64 has not /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so but /usr/lib/alsa-lib/libasound_module_pcm_pulse.so Blender taken from blender.org says ALSA lib pcm.c:2171:(snd_pcm_open_conf) Cannot open shared library /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so Couldn't open audio: No available audio device Why this plugin is not into 64 bits package ?