Bug#831355: pulseaudio: Use module-udev-detect instead of module-detect

[Francois Mescam]

Package: pulseaudio
Version: 9.0-1.1
Severity: minor

Dear Maintainer,

In syslog I saw messages like this one :

pulseaudio[4977]: [pulseaudio] module.c: module-detect is deprecated: Please use
module-udev-detect instead of module-detect!

It's not urgent but this has to be corrected.

With my best regards

François

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii adduser 3.115
ii libasound2 1.1.1-2
ii libasound2-plugins 1:1.1.1-dmo1
ii libc6 2.23-1
ii libcap2 1:2.25-1
ii libdbus-1-3 1.10.8-1
ii libfftw3-single3 3.3.4-2+b1
ii libgcc1 1:6.1.1-9
ii libice6 2:1.0.9-1+b1
ii libltdl7 2.4.6-0.1
ii liborc-0.4-0 1:0.4.25-1
ii libpulse0 9.0-1.1
ii libsm6 2:1.2.2-1+b1
ii libsndfile1 1.0.25-10
ii libsoxr0 0.1.2-1
ii libspeexdsp1 1.2~rc1.2-1
ii libstdc++6 6.1.1-9
ii libsystemd0 230-5
ii libtdb1 1.3.9-1
ii libudev1 230-5
ii libwebrtc-audio-processing1 0.3-1
ii libx11-6 2:1.6.3-1
ii libx11-xcb1 2:1.6.3-1
ii libxcb1 1.11.1-1
ii libxtst6 2:1.2.2-1+b1
ii lsb-base 9.20160629
ii pulseaudio-utils 9.0-1.1

Versions of packages pulseaudio recommends:
pn pulseaudio-module-udev <none>
ii pulseaudio-module-x11 9.0-1.1
ii rtkit 0.11-4

Versions of packages pulseaudio suggests:
pn paman <none>
pn paprefs <none>
ii pavucontrol 3.0-3+b2
pn pavumeter <none>

-- no debconf information

[Felipe Sateler]

On 14 July 2016 at 16:18, Francois Mescam <fran...@mescam.org> wrote:
> Package: pulseaudio
> Version: 9.0-1.1
> Severity: minor
>
> Dear Maintainer,
>
> In syslog I saw messages like this one :
>
> pulseaudio[4977]: [pulseaudio] module.c: module-detect is deprecated: Please use
> module-udev-detect instead of module-detect!
>
> It's not urgent but this has to be corrected.

<snip>

> Versions of packages pulseaudio recommends:
> pn pulseaudio-module-udev <none>

You do not have the udev module installed. Have you disabled
installation of Recommends?



--

Saludos,
Felipe Sateler

[Francois Mescam]

Thanks after installing pulseaudio-module-udev the message disappear.

I have not disbled installation of Recommends but I install them manually and I think I've miss to install this package.

You can close the bug.

Regards

-- 
 Francois Mescam 

[Sean Laguna]

On Fri, 15 Jul 2016 10:08:52 -0400 Felipe Sateler <fsat...@debian.org> wrote:

> On 15 July 2016 at 03:51, Francois Mescam <fran...@mescam.org> wrote:
> > Thanks after installing pulseaudio-module-udev the message disappear.
> >
> > I have not disbled installation of Recommends but I install them manually
> > and I think I've miss to install this package.
> >
> > You can close the bug.
>

> OK, doing so.
>
> --
>
> Saludos,
> Felipe Sateler

I think a problem here is that Debian recently removed this module from the base pulseaudio package: http://lists.alioth.debian.org/pipermail/pkg-pulseaudio-devel/2016-April/006197.html. Like the OP, I had to manually install it to get my default behavior back. It is a bit misleading because in the pulseaudio configuration file, we have the following:

### Automatically load driver modules depending on the hardware available

.ifexists module-udev-detect.so

load-module module-udev-detect

.else

### Use the static hardware detection module (for systems that lack udev support)

load-module module-detect

.endif

 

So... the default config will load this if present, but not having pulseaudio-module-udev installed does not really trigger an error or warning (other than what OP showed). The reason I noticed is because while previously I had separate volume controls for headphones and speakers, I started having just one volume for both. Of course this is bad because I'm used to my volume becoming much lower when I plug my headphones in! I then looked and realized that the udev module was not being loaded, and managed to figure out the above info.

I am not sure what to do to fix this problem, but I can't imagine that very many people want pulseaudio without the udev module. Maybe putting a notice for the next pulseaudio upgrade would be nice, so people can know to install it if they myseriously lost this functionality.

Sean

[Felipe Sateler]

On 21 July 2016 at 21:43, Sean Laguna <sean....@gmail.com> wrote:
> On Fri, 15 Jul 2016 10:08:52 -0400 Felipe Sateler <fsat...@debian.org>
> wrote:
>> On 15 July 2016 at 03:51, Francois Mescam <fran...@mescam.org> wrote:
>> > Thanks after installing pulseaudio-module-udev the message disappear.
>> >
>> > I have not disbled installation of Recommends but I install them
>> > manually
>> > and I think I've miss to install this package.
>> >
>> > You can close the bug.
>>
>> OK, doing so.
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>
> I think a problem here is that Debian recently removed this module from the
> base pulseaudio package:
> http://lists.alioth.debian.org/pipermail/pkg-pulseaudio-devel/2016-April/006197.html.
> Like the OP, I had to manually install it to get my default behavior back.

Did you configure apt to not install Recommends by default?



--

Saludos,
Felipe Sateler

[Josh Triplett]

I ran into this same problem on upgrade, and yes, I have apt configured
to not install Recommends. The default Recommends of core packages
install far too much; over time, that has been fixed somewhat, and I do
look forward to re-enabling it someday. I've filed various bugs on
packages with excessive Recommends, as have many other people, and I've
seen several threads on debian-devel about what the default installation
installs.

In the meantime, though: why split module-udev-detect into a separate
module at all? The main pulseaudio package still depends on udev and
libudev1, and several other components in the core package use it, so
this doesn't reduce dependencies at all; it just introduces the
possibility of breakage like this.

Would you consider either merging module-udev-detect back into
pulseaudio, or making it a Depends?

- Josh Triplett

[Felipe Sateler]

Recommends exist for a reason. Moving a Recommends to a Depends takes
freedom away from users. Why do people who disable installation of
Recommends insist that this freedom be removed (for other users)? From
where I stand, the burden of is on their side for ignoring the
distribution recommendations.

> In the meantime, though: why split module-udev-detect into a separate
> module at all? The main pulseaudio package still depends on udev and
> libudev1, and several other components in the core package use it, so
> this doesn't reduce dependencies at all; it just introduces the
> possibility of breakage like this.

It only depends on libudev, not on the udev daemon.

The story is as follows:

1. The default pulseaudio script loads module-udev-detect if it is available.
2. If it fails to load the daemon start fails.
3. The module fails to load if the udev daemon cannot be contacted.
4. I want pulseaudio to be installable and usable inside containers
(contacting eg, remote sinks).
5. udev does not start inside containers.

Upstream maintains that 3 is correct behavior. So to support
containers without config changes by the user we need to either make
sure module-udev-detect can be unavailable, or ignore udev load
errors. The latter seems very undesirable, so that leaves us only
making it possible to not install module-udev-detect. This also has
the side benefit of not requiring a useless udev daemon inside the
container. I hope this makes clear why this was implemented.

> Would you consider either merging module-udev-detect back into
> pulseaudio, or making it a Depends?

I'm still thinking about it. To be honest, I don't particularly like
making inferior packages to accomodate a non-default setting that
should only be used with care (after all, Recommends is defined as
stuff that almost always should be installed together). On the other
hand, I don't want to deal with endless bug reports either. So I'm
still undecided...


--

Saludos,
Felipe Sateler

[Josh Triplett]

On Thu, Jul 28, 2016 at 10:04:41AM -0400, Felipe Sateler wrote:
> On 28 July 2016 at 02:30, Josh Triplett <jo...@joshtriplett.org> wrote:
> > In the meantime, though: why split module-udev-detect into a separate
> > module at all? The main pulseaudio package still depends on udev and
> > libudev1, and several other components in the core package use it, so
> > this doesn't reduce dependencies at all; it just introduces the
> > possibility of breakage like this.
>
> It only depends on libudev, not on the udev daemon.

I misread https://packages.debian.org/sid/pulseaudio at a quick glance;
it showed "dep: udev (>= 143) [powerpcspe, sh4, x32]", and I missed the
architecture list at first glance. (Those architectures have an out of
date version of pulseaudio.)

> The story is as follows:
>
> 1. The default pulseaudio script loads module-udev-detect if it is available.
> 2. If it fails to load the daemon start fails.
> 3. The module fails to load if the udev daemon cannot be contacted.
> 4. I want pulseaudio to be installable and usable inside containers
> (contacting eg, remote sinks).
> 5. udev does not start inside containers.
>
> Upstream maintains that 3 is correct behavior. So to support
> containers without config changes by the user we need to either make
> sure module-udev-detect can be unavailable, or ignore udev load
> errors. The latter seems very undesirable, so that leaves us only
> making it possible to not install module-udev-detect. This also has
> the side benefit of not requiring a useless udev daemon inside the
> container. I hope this makes clear why this was implemented.

It does, yes.

1, 3, 4, and 5 seem reasonable; 2 seems like the problem. Why does
ignoring module-udev-detect load errors (when the alternative is
completely failing to start) seem undesirable? Ideally, pulseaudio
should attempt to load module-udev-detect, and if that fails, load
module-detect instead rather than giving up.

- Josh Triplett

[Felipe Sateler]

Unfortunately the pulseaudio loader scripts are not very expressive so
I don't think that is possible to achieve.

I discussed this with upstream:

<fsateler> tanuk: do you recall/know why does the default.pa loads
module-udev under a .fail section?
<fsateler> context is, people were complaining due to the module-udev
split into a separate package
<tanuk> fsateler: I don't remember, but I would guess that there's no
reason for module-udev-detect to fail if it's present.
<tanuk> fsateler: How is the package split related?
<tanuk> module-udev-detect is guarded by .ifexists module-udev-detect.so
<tanuk> So there should be no failure if the module isn't installed.
<tanuk> fsateler: Hmm, maybe you were considering to remove that
.ifexists check, and you'd like module-udev-detect to fail gracefully
if udev isn't present/usable.
<tanuk> fsateler: IIRC, this was discussed earlier (with you?), and my
take-away was that while it has some drawbacks, it would be best if
module-udev-detect would fail gracefully when it can't connect to
udev.
<tanuk> Nobody has submitted a patch, however.
<fsateler> (sorry, got kidnapped into a meeting)
<fsateler> tanuk: it is related because a user was asking why not
simply ship the udev module, and have it fail if udev is not available
<fsateler> or in other words, a reason for the split is that the
daemon fails to start if the module fails to load
<fsateler> so a user asked why would the daemon fail to start. and I
didn't have an answer to that ;)
<fsateler> tanuk: is it possible for a module to exit gracefully with
"nothing to do" ?
<tanuk> fsateler: Yes.
<tanuk> Well, there's no special return code for "nothing to do".
<tanuk> We have module-combine, which is deprecated and just loads
module-combine-sink and then does nothing (module-combine still stays
loaded).
<tanuk> And module-hal-detect-compat loads module-udev-detect, and
also requests itself to be unloaded after that.
<fsateler> ok
<fsateler> so I guess the way forward would be to make a patch for
module-udev-detect to just: if (!connect_to_udev()) { return 0; }
<fsateler> or something similar in spirit
<tanuk> Yes. And include a comment why it's desirable to support
systems that want to have module-udev-detect installed when udev isn't
available.
<fsateler> ok
<fsateler> tanuk: do you mind if I copy paste this conversation into
the bug log?
<tanuk> Feel free.


So the way forward would be to patch module-udev-detect to exit
gracefully if udev is not present. One could even chain load
module-detect if udev is not available.

I guess patches welcome :).

--

Saludos,
Felipe Sateler

[Josh Triplett]

On Fri, Jul 29, 2016 at 10:51:09AM -0400, Felipe Sateler wrote:
> I discussed this with upstream:

[...snip...]

> So the way forward would be to patch module-udev-detect to exit
> gracefully if udev is not present. One could even chain load
> module-detect if udev is not available.

Chain-loading module-detect seems sensible, rather than just silently
doing nothing. (module-udev-detect should probably emit a log message
in this case, to aid in debugging.)