Bug#900856: enlightenment: Sound fails to work after upgrade
On Fri, Jun 29, 2018 at 3:26 AM Mike Brodbelt wrote: > On 29/06/18 04:26, Felipe Sateler wrote: > > > Thanks. However, it has some flaws that need to be reworked for this to > > work at all: > > > > 1. We can't rely on gcc being installed > > Would "dpkg-architecture -qDEB_BUILD_MULTIARCH" be a reasonable > replacement? > Unfortunately not. It is part of dpkg-dev, which is also not installed by default (and requiring it via pulseaudio doesn't make much sense). I think using /proc/1/comm or /proc/1/exe are better alternatives. > > 2. It doesn't check /proc is actually mounted > > 3. dpkg status check is racy: sysvinit might be upgraded at the same > > time, and thus not be "installed" > > 4. dpkg status check is for the wrong package: sysvinit no longer exists > > (I think you want sysvinit-core). > > 5. The postinst should be the one for libpulse0, not pulseaudio > > Will have a poke at these when I get a minute. > > > You missed the conffile mark because it is shipped in libpulse0 :) > > That would explain that :-) > > > I don't have objections in principle, but I want a good and relatively > > not-risky implementation first. > > Ack. > > > BTW, it might be easier to do the review/fixup dance in a merge request > > on salsa: https://salsa.debian.org/pulseaudio-team/pulseaudio > > OK. Haven't played with that before, but will have a look. > It's not strictly required, but I would prefer that, thanks. -- Saludos, Felipe Sateler
Bug#900856: enlightenment: Sound fails to work after upgrade
On 29/06/18 04:26, Felipe Sateler wrote: Thanks. However, it has some flaws that need to be reworked for this to work at all: 1. We can't rely on gcc being installed Would "dpkg-architecture -qDEB_BUILD_MULTIARCH" be a reasonable replacement? 2. It doesn't check /proc is actually mounted 3. dpkg status check is racy: sysvinit might be upgraded at the same time, and thus not be "installed" 4. dpkg status check is for the wrong package: sysvinit no longer exists (I think you want sysvinit-core). 5. The postinst should be the one for libpulse0, not pulseaudio Will have a poke at these when I get a minute. You missed the conffile mark because it is shipped in libpulse0 :) That would explain that :-) I don't have objections in principle, but I want a good and relatively not-risky implementation first. Ack. BTW, it might be easier to do the review/fixup dance in a merge request on salsa: https://salsa.debian.org/pulseaudio-team/pulseaudio OK. Haven't played with that before, but will have a look. Mike
Bug#900856: enlightenment: Sound fails to work after upgrade
Hi Mike, On Thu, Jun 28, 2018 at 6:15 PM Mike Brodbelt wrote: > On 21/06/18 12:34, Felipe Sateler wrote: > > > Patches welcome. If you decide to implement this, make sure that the > > code is only active with a running sysvinit (ie, don't affect chroots). > > It is not trivial, which is why I didn't implement it myself. You > > probably need to integrate ucf to handle all the corner cases. > > Patch attached. Thanks. However, it has some flaws that need to be reworked for this to work at all: 1. We can't rely on gcc being installed 2. It doesn't check /proc is actually mounted 3. dpkg status check is racy: sysvinit might be upgraded at the same time, and thus not be "installed" 4. dpkg status check is for the wrong package: sysvinit no longer exists (I think you want sysvinit-core). 5. The postinst should be the one for libpulse0, not pulseaudio I would suggest poking around in /proc/1/ instead to check for sysvinit. > I haven't gone through all the steps of integrating ucf > - the disable autospawn file isn't currently marked in the package as a > conffile, so this patch, while it works in my limited testing, could > still be improved on there. > You missed the conffile mark because it is shipped in libpulse0 :) > > LMK what you think - if you're happy with this approach and will > integrate it, I can work on ucf integration as well. > I don't have objections in principle, but I want a good and relatively not-risky implementation first. BTW, it might be easier to do the review/fixup dance in a merge request on salsa: https://salsa.debian.org/pulseaudio-team/pulseaudio -- Saludos, Felipe Sateler
Bug#900856: enlightenment: Sound fails to work after upgrade
On 21/06/18 12:34, Felipe Sateler wrote:
Patches welcome. If you decide to implement this, make sure that the
code is only active with a running sysvinit (ie, don't affect chroots).
It is not trivial, which is why I didn't implement it myself. You
probably need to integrate ucf to handle all the corner cases.
Patch attached. I haven't gone through all the steps of integrating ucf
- the disable autospawn file isn't currently marked in the package as a
conffile, so this patch, while it works in my limited testing, could
still be improved on there.
LMK what you think - if you're happy with this approach and will
integrate it, I can work on ucf integration as well.
Mike
--- /var/lib/dpkg/info/pulseaudio.postinst 2018-04-05 19:55:56.0 +0100
+++ pulseaudio.postinst 2018-06-28 23:01:17.801244088 +0100
@@ -16,6 +16,34 @@
PULSEAUDIO=/usr/bin/pulseaudio
+check_sysvinit() {
+ # Get the major/minor numbers for the root device
+ local rdev=$(printf %04.0f $(stat -c %D /) | sed 's/../&:/')
+ # Get the default target triplet for the system
+ local arch=$(gcc -print-multiarch)
+ # Retrieve PID 1's mapped binaries from the root fs
+ local binmaps=`awk "/$rdev/ {print \\$6}" /proc/1/maps | grep -v $arch | uniq | xargs`
+
+ local status
+ status=$(dpkg -s sysvinit 2>/dev/null | grep ^Status: | sed -e 's/^Status: \(.*\) \(.*\) \(.*\)/\3/g')
+
+ # If the sysvinit package is installed, and it's binary is mapped as PID 1,
+ # then we can assume we are on a sysvinit system, and not simply in a chroot
+ # environment.
+ if [ -n "$status" ] && [ "$status" == "installed" ]; then
+ if [ -n "$binmaps" ] && [ "$binmaps" == "/sbin/init" ]; then
+ return 0
+ fi
+ fi
+ return 1
+}
+
+config_autospawn() {
+ if check_sysvinit; then
+ rm -f /etc/pulse/client.conf.d/00-disable-autospawn.conf
+ fi
+}
+
trigger_udev() {
if ! which udevadm >/dev/null 2>&1 ; then
return 0;
@@ -36,6 +64,7 @@
addgroup --quiet --system pulse-access
fi
trigger_udev
+config_autospawn
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
Bug#900856: enlightenment: Sound fails to work after upgrade
On Wed, Jun 20, 2018, 19:51 Mike Brodbelt wrote: > On 19/06/18 02:35, Ross Vandegrift wrote: > > > While upgrading a different machine from stretch -> buster, I noticed > > the following in apt-listchanges output: > > > > pulseaudio (11.1-2) unstable; urgency=medium > > > >* Since this version, pulseaudio disables autospawn by default on > linux > > systems, and replaces that with systemd socket activation. If you > are not > > using systemd, then please edit or remove > > /etc/pulse/client.conf.d/00-disable-autospawn.conf > > to re-enable it. > > > > Seems relevant to your issue - the grep above didn't look in > > /etc/pulse/client.conf.d. > > Many thanks, that seems to be it, and that behaviour change is fairly > non obvious without reading the changelog. > > Perhaps the pulseaudio postinstall script could do a better job here? It > should be possible to detect the active init system on install, and not > disable autospawn unless systemd is positively detected, surely. > Patches welcome. If you decide to implement this, make sure that the code is only active with a running sysvinit (ie, don't affect chroots). It is not trivial, which is why I didn't implement it myself. You probably need to integrate ucf to handle all the corner cases. Saludos
Bug#900856: enlightenment: Sound fails to work after upgrade
On 19/06/18 02:35, Ross Vandegrift wrote: While upgrading a different machine from stretch -> buster, I noticed the following in apt-listchanges output: pulseaudio (11.1-2) unstable; urgency=medium * Since this version, pulseaudio disables autospawn by default on linux systems, and replaces that with systemd socket activation. If you are not using systemd, then please edit or remove /etc/pulse/client.conf.d/00-disable-autospawn.conf to re-enable it. Seems relevant to your issue - the grep above didn't look in /etc/pulse/client.conf.d. Many thanks, that seems to be it, and that behaviour change is fairly non obvious without reading the changelog. Perhaps the pulseaudio postinstall script could do a better job here? It should be possible to detect the active init system on install, and not disable autospawn unless systemd is positively detected, surely. Mike
Bug#900856: enlightenment: Sound fails to work after upgrade
On Fri, Jun 15, 2018 at 12:48:51AM +0100, Mike Brodbelt wrote: > $ cd ~ && grep autospawn .config/pulse/client.conf /etc/pulse/client.conf > grep: .config/pulse/client.conf: No such file or directory > /etc/pulse/client.conf:; autospawn = yes > > It's possible this is a bug in pulseaudio directly, as the problem seems to > be that the autospawn behaviour is not working correctly. Hi Mike, While upgrading a different machine from stretch -> buster, I noticed the following in apt-listchanges output: pulseaudio (11.1-2) unstable; urgency=medium * Since this version, pulseaudio disables autospawn by default on linux systems, and replaces that with systemd socket activation. If you are not using systemd, then please edit or remove /etc/pulse/client.conf.d/00-disable-autospawn.conf to re-enable it. Seems relevant to your issue - the grep above didn't look in /etc/pulse/client.conf.d. Ross
Bug#900856: enlightenment: Sound fails to work after upgrade
Control: reassign -1 pulseaudio On Fri, Jun 15, 2018 at 12:48:51AM +0100, Mike Brodbelt wrote: > > > $ start-pulseaudio-x11 > > > Connection failure: Connection refused > > > pa_context_connect() failed: Connection refused > > > > This is curious. According to start-pulseaudio-x11(1), it should start a > > daemon if required. > > My man page also claims this. The shell script itself just runs "pactl" > commands. As far as I can tell, this attempts to connect to a PulseAudio > server, and fails - the startup of a daemon seems to rely on the autospawn > functionality. The seemingly canonical docs are here: > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ > > are quite clear that this should autostart the server, unless "autospawn" is > disabled, which it is not (it's in the debian default config):- > > $ cd ~ && grep autospawn .config/pulse/client.conf /etc/pulse/client.conf > grep: .config/pulse/client.conf: No such file or directory > /etc/pulse/client.conf:; autospawn = yes > > It's possible this is a bug in pulseaudio directly, as the problem seems to > be that the autospawn behaviour is not working correctly. Spawning manually works reliably. In the working cases (your E17 on buster, my E22 on buster) pulse is started outside of E. So this seems most likely. Ross
Bug#900856: enlightenment: Sound fails to work after upgrade
On Tue, Jun 05, 2018 at 11:01:35PM +0100, Mike Brodbelt wrote: > Doing some investigation into this, I enabled "PulseAudio Sound System" > in Settings > Apps > Startup Applications. This didn't work - it seems > to execute 'start-pulseaudio-x11' at login, which fails because it's > executed at a point at which there is no pulseaudio daemon running:- This shouldn't be required - my Startup Applications doesn't include pulse. What does "systemctl --user status pulseaudio.service" report? On my buster laptop, it reports that the service is running and enabled. > $ start-pulseaudio-x11 > Connection failure: Connection refused > pa_context_connect() failed: Connection refused This is curious. According to start-pulseaudio-x11(1), it should start a daemon if required. Ross
Bug#900856: enlightenment: Sound fails to work after upgrade
Package: enlightenment Version: 0.22.1-3 Severity: normal After upgrading from the venerable e17 package, sounds stopped working entirely on my desktop. I am not 100% certain whether the situation here is a bug in the Enlightenment package, or elsewhere, but I'm filing it here as it was triggered by an upgrade to E. Doing some investigation into this, I enabled "PulseAudio Sound System" in Settings > Apps > Startup Applications. This didn't work - it seems to execute 'start-pulseaudio-x11' at login, which fails because it's executed at a point at which there is no pulseaudio daemon running:- $ start-pulseaudio-x11 Connection failure: Connection refused pa_context_connect() failed: Connection refused Sound can be fairly trivially re-enabled by starting the user daemon from a terminal after login:- $ pulseaudio --start --log-target=syslog At this point, it's still necessary to go into the settings for the mixer, and click "apply" without making any changes, at which point sound is usable as expected. According to docs, the pulseaudio daemon is supposed to be auto-spawned on demand if the libraries are used, but that appears not to be happening. My startup sequence is lightdm -> Enlightenment, and the autospawn setting of pulseaudio has not been changed from the Debian default. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (750, 'unstable'), (500, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages enlightenment depends on: ii dbus-x11 [dbus-session-bus] 1.12.8-2 ii enlightenment-data 0.22.1-3 ii libasound2 1.1.6-1 ii libbluetooth35.49-4 ii libc62.27-3 ii libecore-con11.20.7-4 ii libecore-evas1 1.20.7-4 ii libecore-file1 1.20.7-4 ii libecore-input1 1.20.7-4 ii libecore-ipc11.20.7-4 ii libecore-x1 1.20.7-4 ii libecore11.20.7-4 ii libedje-bin 1.20.7-4 ii libedje1 1.20.7-4 ii libeet1 1.20.7-4 ii libeeze1 1.20.7-4 ii libefreet-bin1.20.7-4 ii libefreet1a 1.20.7-4 ii libeina1a1.20.7-4 ii libeio1 1.20.7-4 ii libelementary1 1.20.7-4 ii libemile11.20.7-4 ii libemotion1 1.20.7-4 ii libevas1 1.20.7-4 ii libevas1-engines-x 1.20.7-4 ii libpam0g 1.1.8-3.7 ii libpulse011.1-5 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb-shape01.13-1 ii libxcb1 1.13-1 Versions of packages enlightenment recommends: ii gnome-terminal [x-terminal-emulator] 3.28.2-1 ii pm-utils 1.4.1-18 ii terminology [x-terminal-emulator] 1.2.1-1 ii xterm [x-terminal-emulator] 333-1 enlightenment suggests no packages. -- no debconf information
