configure.ac has PA_MACHINE_ID="${localstatedir}/lib/dbus/machine-id" but it should have PA_MACHINE_ID="${sysconfdir}/machine-id" since machine-id is in /etc instead of /var/lib/dbus since >=sys-apps/dbus-1.4.16-r2 in reality, upstream pulseaudio should have similar code to: http://cgit.freedesktop.org/dbus/dbus/commit/dbus/dbus-sysdeps-unix.c?id=66e52541d5bdd4927a5c702963749760643313f4
Thanks for the report Samuli. I noticed that upstream doesn't actually mention putting machine-id in /etc/ in dbus (the commit you pointed to actually mentions that /etc/machine-id is set up by systemd and meant to be a fallback). Upstream Makefile.am even has this: AM_CPPFLAGS = \ -I$(top_builddir) \ -I$(top_srcdir) \ -DDBUS_COMPILATION \ -DDBUS_MACHINE_UUID_FILE=\""$(localstatedir)/lib/dbus/machine-id"\" \ -DDBUS_SYSTEM_CONFIG_FILE=\""$(configdir)/system.conf"\" \ -DDBUS_SESSION_CONFIG_FILE=\""$(configdir)/session.conf"\" \ $(NULL) That said, I don't actually have /var/lib/dbus/machine-id (I do have /etc/machine-id not owned by any program). Any further clues as to how this is supposed to work? I have a patch to PA to fallback to /etc/machine-id done. Will push once we clarify things.
I'm not sure how our systemd maintainers will handle this in systemd package itself, use the machine-id generated by dbus-uuidgen or overwrite it in /etc: Bug 370451, Comment #0 But I don't think it should be relavent to committing the patch to pulseaudio or not, it should support the fallback in any case. Please (re?)read comments in http://bugzilla.gnome.org/show_bug.cgi?id=663928 before pushing
(In reply to comment #2) > I'm not sure how our systemd maintainers will handle this in systemd package > itself, use the machine-id generated by dbus-uuidgen or overwrite it in /etc: > > Bug 370451, Comment #0 > > But I don't think it should be relavent to committing the patch to pulseaudio > or not, it should support the fallback in any case. It is relevant because I have 3 conflicting data points: 1. You say that /etc/machine-id is the only currently relevant place to look (whether you're running dbus or systemd) 2. The dbus sources seem to show /var/lib/... as still the default s. 3. I don't have a /var/lib/... on my local question Which is why I'm wondering what I'm missing in all thi
all i'm asking is matching behavior from pulseaudio with dbus (and glib) to first look in /var/lib/dbus/machine-id, and then fallback to /etc/machine-id if not found
Pushed upstream. Is this a systemd-only issue, or a general one? That is, does it merit causing yet another recompile with a revbump?
general one, and it's screwing kde startup over (causes it to stall) so revbump is necessary
any ETA on this? there really isn't usable pulse in ~arch now...
Sorry, this dropped off my radar. Should fix this up today (just resolving what other fixes from master need to be cherry-picked).
Finally fixed with 1.1-r1. Apologies for the delay.
this has broken skype for some strange reason. might need to bump the 32bit emul package to resolve that
Yes, true -- the emul packages need to be rebuilt to get refreshed dbus and pulseaudio.
(In reply to comment #11) > Yes, true -- the emul packages need to be rebuilt to get refreshed dbus and > pulseaudio. ... but this is not the bug to handle that. file a new bug so it can be assigned to the amd64 team for rebuilding them with latest dbus/pulseaudio. you can mention this bug as a reference.
will do
