Package: paprefs
Version: 0.9.9-2
Severity: grave
Dear Maintainer, paprefs search incorrect module path as follows:
$ strace paprefs 2>&1 | grep /lib/pulse
access("/usr/lib/pulse-1.1.0/modules/module-esound-protocol-tcp.so", F_OK) =
-1 ENOENT (No such file or directory)
access("/usr/lib/p
In the meantime, a hacky workaround:
$ sed -s 's/pulse-0.9.15/pulse-0.9.19/g' < /usr/bin/paprefs > ~/paprefs
$ chmod u+x ./paprefs
$ ./paprefs
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debia
Upstream bug report: http://www.pulseaudio.org/ticket/688
--
Will Dyson
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The cause of this annoying problem is that when paprefs checks for the
availability of the modules to implement these services, it does so
using a compiled-in filesystem location. Pulseaudio modules live in a
versioned library directory (/usr/lib/pulse-). So, it checks
for the modules in the locati
I've solved this problem by upgrading from 0.9.6-2 to 0.9.8-1. We should
try to get that version into testing soon.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
*sigh* It is tremendously disappointing to get a handle on
one set of problems with this package only to find
there is a new set of problems with a different area
(in this case network audio).
I can see the checks on the 'Enable network access to local sound
device' and 'Allow other machines on
Package: paprefs
Version: 0.9.6-2
Severity: normal
I have pulseaudio running as a regular user (i.e. I start when I start my X
session), and when I run paprefs all the 'Network Access' options are greyed
out. I temporarily enabled the network by editing ~/.pulse/daemon.conf and
~/.pulse/defau
7 matches
Mail list logo
