Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Oon-Ee Ng
On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens jan.steff...@gmail.comwrote:

 On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
  Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio
  output (running mpd as my own user) fails with the following:-
 
  Nov 19 14:45 : output: Failed to enable MPD Pulse Output [pulse]:
  pa_context_connect() has failed: Connection refused
  Nov 19 14:45 : player_thread: problems opening audio device while playing
  PointBreak-StandTough.mp3
 
  Setting up pulseaudio to listen on TCP locally as in the wiki works, but
 I
  never needed to do that before. Can anyone else verify this? Is it
 perhaps
  logind related (worked fine before this last pulseaudio update)?

 You're running mpd from systemd? I believe it's because PulseAudio now
 uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX,
 $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and
 $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie.

 mpd has no session, so these variables are not set, unlike the session
 you login to.

 This should be sent upstream (bugs.freedesktop.org).


Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up,
but it's unclear to me whether 'upstream' here refers to pulseaudio,
systemd, or mpd. Or even whether its actually wrong behaviour.

My understanding of your explanation is that there's no clear
responsibility. mpd does not use (or require) a session, the locations
pulse uses are fairly standard (I've always hated apps using ~/.foo)...


Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Tom Gundersen
On Nov 19, 2012 10:27 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:

 On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens jan.steff...@gmail.com
wrote:

  On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng ngoonee.t...@gmail.com
wrote:
   Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio
   output (running mpd as my own user) fails with the following:-
  
   Nov 19 14:45 : output: Failed to enable MPD Pulse Output [pulse]:
   pa_context_connect() has failed: Connection refused
   Nov 19 14:45 : player_thread: problems opening audio device while
playing
   PointBreak-StandTough.mp3
  
   Setting up pulseaudio to listen on TCP locally as in the wiki works,
but
  I
   never needed to do that before. Can anyone else verify this? Is it
  perhaps
   logind related (worked fine before this last pulseaudio update)?
 
  You're running mpd from systemd? I believe it's because PulseAudio now
  uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX,
  $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and
  $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie.
 
  mpd has no session, so these variables are not set, unlike the session
  you login to.
 
  This should be sent upstream (bugs.freedesktop.org).
 

 Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up,
 but it's unclear to me whether 'upstream' here refers to pulseaudio,
 systemd, or mpd. Or even whether its actually wrong behaviour.

 My understanding of your explanation is that there's no clear
 responsibility. mpd does not use (or require) a session, the locations
 pulse uses are fairly standard (I've always hated apps using ~/.foo)...

This was recently discussed:
http://arunraghavan.net/2012/11/pulseconf-2012-report/

Does not look like anything has come of it yet. I guess it might make sense
to ask advice from the PA guys though, they would hopefully have an idea.

Tom


[arch-general] LVM Thin Provisioning

2012-11-19 Thread Squall Lionheart
Hello,

I have been reading about Thin Provisioning in LVM and wanted to play with
it however, when I try to create a thin pool it shows an error saying:

# lvcreate --thinpool -L 1G vg/pool
  WARNING: Unrecognised segment type thin
  Unable to create LV with unknown segment type thin.
  Run `lvcreate --help' for more information.

I am running version:

# lvm version
  LVM version: 2.02.98(2) (2012-10-15)
  Library version: 1.02.77 (2012-10-15)
  Driver version:  4.23.0

and have the following targets for device mapper:

# dmsetup targets
snapshot-merge   v1.1.0
snapshot-origin  v1.7.1
snapshot v1.10.0
zero v1.0.0
striped  v1.5.0
linear   v1.1.0
errorv1.0.1

According to what I could find, this feature has been available since
version 2.02.89 and is enabled with the compile time option of
--with-thin=internal, but doesn't appear to be enabled in the Arch
package.  Am I correct or does something need to be configured on my
machine?

Thank you
Squall


-- 
Yesterday is history.
Tomorrow is a mystery.
Today is a gift.
That's why its called the present.

Headmaster Squall :: The Wired/Section-9
Close the world  txen eht nepo
$3R14L 3XP3R1M3NT$ #L41N
https://github.com/headmastersqual http://twitter.com/headmastersquall


[arch-general] community repository and old versions of updated packages

2012-11-19 Thread Jens Arm
Hi ArchLinux-Team


For some months now I'm using ArchLinux (i686) and I like it much.

I use a local package mirror which I sometimes update using rsync.
Since about 2 weeks I found out that old package versions of updated 
packages in the community repository not get deleted anymore.
core and extra is OK.

Here an example of e.g. filezilla which gets last updated on 19.11:

./ArchLinux/community/os/i686/filezilla-3.5.3-1-i686.pkg.tar.xz
./ArchLinux/community/os/i686/filezilla-3.5.3-1-i686.pkg.tar.xz.sig
./ArchLinux/community/os/i686/filezilla-3.6.0-1-i686.pkg.tar.xz
./ArchLinux/community/os/i686/filezilla-3.6.0-1-i686.pkg.tar.xz.sig
./ArchLinux/community/os/i686/filezilla-3.6.0.1-1-i686.pkg.tar.xz
./ArchLinux/community/os/i686/filezilla-3.6.0.1-1-i686.pkg.tar.xz.sig

Is this known or a bug?


regards
   Jens


[arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Jérôme Bartand
I want to bring to your attention that Gentoo is working on a udev fork
called eudev that will

- respect the Unix philosophy
- be POSIX-compliant and get rid of glibcisms
- have no unnecessary dependencies (systemd, kmod)
- support separate /usr

http://thread.gmane.org/gmane.linux.gentoo.project/2262

with the goal to make it default for Gentoo in the future, along with
OpenRC. I know from past discussions on this mailing list that not
everybody in the Arch community is happy with systemd. They are looking for
contributors and this is an opportunity for cross-community collaboration.

Regards,
-J


Re: [arch-general] community repository and old versions of updated packages

2012-11-19 Thread Florian Pritz
On 19.11.2012 20:51, Jens Arm wrote:
 I use a local package mirror which I sometimes update using rsync.
 Since about 2 weeks I found out that old package versions of updated 
 packages in the community repository not get deleted anymore.
 core and extra is OK.

 Is this known or a bug?

Looks like the cleanup script cronjob is missing on the new server. I'll
see what I can do. Thanks for telling us.

-- 
Florian Pritz



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Dave Reisner
I normally wouldn't respond to trolls on this list and really I'd rather
have seen this post be moderated straight to where it belongs -- /dev/null.
However

On Mon, Nov 19, 2012 at 2:31 PM, Jérôme Bartand moije...@gmail.com wrote:

 I want to bring to your attention that Gentoo is working on a udev fork
 called eudev that will

 - respect the Unix philosophy


Sorry, perhaps you could explain how current udev (udev, not systemd)
defies this, and why it's relevant for a small set of binaries and library
which only serve to handle uevents from the kernel. Please keep in mind
when writing your response that udev is still entirely useable without
systemd. No, Lennart's infamous post exclaiming how standalone udev has no
future is not an indication that it's going to break any time soon.


 - be POSIX-compliant and get rid of glibcisms


Why does this matter? Do you have any concept of what POSIX defines and
doesn't define? udev is a piece of software which is intimately involved
with the Linux kernel, and necessarily must be, to accomplish its goals.
Furthermore, the glibcisms used by udev has nearly wholly been adopted by
the other popular libcs -- eglibc, uclibc, and musl.


 - have no unnecessary dependencies (systemd, kmod)


You seem to have this backwards. systemd relies on udev, not vice versa.
kmod is a real thing which solves a real problem. Going back to
module-init-tools causes unsolvable regressions which were addressed by the
implementation of a library which userspace has been lacking for years, and
which was developed after much talk at the Linux Plumbers conference a year
ago. Jon Masters and Rusty Russel both strongly support the implementation
of libkmod, as do other people who are well known in low level userspace
and kernel space as well. Feel free to point out why this is a bad idea.


 - support separate /usr


Please explain why udev makes this a non-reality. A properly working
separate /usr without an initramfs is a unicorn. It's been broken long
before udev did whatever you think it did to break it. It's hopelessly
pointless to do, and if you're still bent on it, the modern initramfs
implementations support mounting a separate /usr from early userspace, and
cleanly unmounting it on shutdown. Do you have any concept of what the
problems associated with this are? You can't possibly, or else you wouldn't
be parroting this tripe.



 http://thread.gmane.org/gmane.linux.gentoo.project/2262


Maybe you should have pointed out this thread:

http://gentoo.2317880.n4.nabble.com/udev-ng-Was-Summary-Council-meeting-Tuesday-13-November-2012-td252237.html

Which really only points out how flawed their non-existant plan is, and how
much resistance they're getting to the idea. I can only assume you haven't
actually read it.


 with the goal to make it default for Gentoo in the future, along with
 OpenRC. I know from past discussions on this mailing list that not
 everybody in the Arch community is happy with systemd. They are looking for
 contributors and this is an opportunity for cross-community collaboration.


Feel free to join them. Your sinking ship awaits you.


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Leonid Isaev
On Mon, 19 Nov 2012 20:31:40 +0100
Jérôme Bartand moije...@gmail.com wrote:

 I want to bring to your attention that Gentoo is working on a udev fork
 called eudev that will
 
 - respect the Unix philosophy
 - be POSIX-compliant and get rid of glibcisms
 - have no unnecessary dependencies (systemd, kmod)
 - support separate /usr
 
 http://thread.gmane.org/gmane.linux.gentoo.project/2262
 
 with the goal to make it default for Gentoo in the future, along with
 OpenRC. I know from past discussions on this mailing list that not
 everybody in the Arch community is happy with systemd. They are looking for
 contributors and this is an opportunity for cross-community collaboration.
 
 Regards,
 -J

This has already been discussed on the forums, in the General Linux section:
https://bbs.archlinux.org/viewtopic.php?id=153063. Please, keep the
eudev-related issues there and do not pollute this ML, as I don't want to
see 300 emails in my mailbox tomorrow...

-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


signature.asc
Description: PGP signature


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Ionut Biru
On 11/19/2012 09:31 PM, Jérôme Bartand wrote:
 I want to bring to your attention that Gentoo is working on a udev fork
 called eudev that will
 
 - respect the Unix philosophy
 - be POSIX-compliant and get rid of glibcisms
 - have no unnecessary dependencies (systemd, kmod)
 - support separate /usr
 
 http://thread.gmane.org/gmane.linux.gentoo.project/2262
 

I find this link to be more useful:
http://cdn.memegenerator.net/instances/400x/30483828.jpg

 with the goal to make it default for Gentoo in the future, along with
 OpenRC. I know from past discussions on this mailing list that not
 everybody in the Arch community is happy with systemd. They are looking for
 contributors and this is an opportunity for cross-community collaboration.
 
 Regards,
 -J
 



-- 
Ionuț



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Gaetan Bisson
[2012-11-19 16:30:10 -0500] Dave Reisner:
 I normally wouldn't respond to trolls on this list and really I'd rather
 have seen this post be moderated straight to where it belongs -- /dev/null.

And you'd normally be right. I've let this message through because it's
short, borderline troll but otherwise informative. Now you've turned
that thread into a flamewar. Well done.

-- 
Gaetan


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Gaetan Bisson
[2012-11-19 15:37:06 -0600] Leonid Isaev:
 This has already been discussed on the forums, in the General Linux section:
 https://bbs.archlinux.org/viewtopic.php?id=153063. Please, keep the
 eudev-related issues there and do not pollute this ML, as I don't want to
 see 300 emails in my mailbox tomorrow...

Just don't reply then. When are you going to get that your message
contributes to the 300... ?

-- 
Gaetan


pgpkbQkZ1VP5i.pgp
Description: PGP signature


[arch-general] A systemd-logind shutdown issue

2012-11-19 Thread Leonid Isaev
Hi,

On all my installations with systemd I am seeing strange errors in
journal/syslog on shutdown. For simplicity, I use systemctl poweroff w/o X.
The error is either


Nov 18 16:37:26 bluemoon login: pam_systemd(login:session): Failed to connect
to system bus: Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy blocked the
reply, the reply timeout expired, or the network connection was broken. 


or 


Nov 13 18:00:02 bluemoon systemd[1]: systemd-logind.service: main process
exited, code=exited, status=1/FAILURE
Nov 13 18:00:02 bluemoon systemd[1]: Stopped Login Service.
Nov 13 18:00:02 bluemoon systemd[1]: Unit systemd-logind.service entered failed
state


I can only achieve clean shutdown if all users are logged out and the power
button is pressed. Somehow, if I simply stop/start systemd-logind.service it
restarts cleanly. So there seems to be a race on shutdown between
systemd-logind and something else (login?). I have seen similar problems on the
web, but noone seems to care...

Any idea how I can get more info about/debug this?

TIA

PS: And yes, the above error occurs independently of the value of
KillUserProcesses.

-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


signature.asc
Description: PGP signature


Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Oon-Ee Ng
On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen t...@jklm.no wrote:

 On Nov 19, 2012 10:27 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
 
  On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens jan.steff...@gmail.com
 wrote:
 
   On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng ngoonee.t...@gmail.com
 wrote:
Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio
output (running mpd as my own user) fails with the following:-
   
Nov 19 14:45 : output: Failed to enable MPD Pulse Output [pulse]:
pa_context_connect() has failed: Connection refused
Nov 19 14:45 : player_thread: problems opening audio device while
 playing
PointBreak-StandTough.mp3
   
Setting up pulseaudio to listen on TCP locally as in the wiki works,
 but
   I
never needed to do that before. Can anyone else verify this? Is it
   perhaps
logind related (worked fine before this last pulseaudio update)?
  
   You're running mpd from systemd? I believe it's because PulseAudio now
   uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX,
   $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and
   $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie.
  
   mpd has no session, so these variables are not set, unlike the session
   you login to.
  
   This should be sent upstream (bugs.freedesktop.org).
  
 
  Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up,
  but it's unclear to me whether 'upstream' here refers to pulseaudio,
  systemd, or mpd. Or even whether its actually wrong behaviour.
 
  My understanding of your explanation is that there's no clear
  responsibility. mpd does not use (or require) a session, the locations
  pulse uses are fairly standard (I've always hated apps using ~/.foo)...

 This was recently discussed:
 http://arunraghavan.net/2012/11/pulseconf-2012-report/

 Does not look like anything has come of it yet. I guess it might make sense
 to ask advice from the PA guys though, they would hopefully have an idea.

 Tom


Thanks Tom, I'll ask on their ML.


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Tom Gundersen
On Mon, Nov 19, 2012 at 8:31 PM, Jérôme Bartand moije...@gmail.com wrote:
 I want to bring to your attention that Gentoo is working on a udev fork
 called eudev

Having read through their discussions, it seems that the main two
things they would like to change is to be able to build udev without
building systemd (this does of course not change the resulting code,
but saves time if you have to build everything locally) and to make
the dependency on kmod optional (this might make sense if you don't
have module support in your kernel, but I think the difference would
not be measurable in any way).

Both of those things should be achievable by (trivial) patches to the
buildsystem, so it is not clear to me why a full fork was necessary.
Moreover, if you look at the commits that went in so far, most of it
is shuffling code around without any functional change, except making
back/forward porting of patches really hard...

-t


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Kevin Chadwick
On Tue, 20 Nov 2012 00:54:31 +0100
Tom Gundersen t...@jklm.no wrote:

 Having read through their discussions, it seems that the main two
 things they would like to change is to be able to build udev without
 building systemd (this does of course not change the resulting code,
 but saves time if you have to build everything locally) and to make
 the dependency on kmod optional (this might make sense if you don't
 have module support in your kernel, but I think the difference would
 not be measurable in any way).

Odd, my take was that the main goal was trying to bring back a
separate /usr.

I did post to the arch-general mailing a while back about why the FSF is
wrong on there being no need for a seperate /usr and putting everything
in there without static core binaries in a smaller root is less
reliable. I now wonder if that is because it was broken anyway and
lennart gave a seemingly reasonable justification that may reduce the
complaints.

The other reason I noted was less dependency on upstream decisions or
breakages and this one may have been the debian list but keeping dbus
off servers.


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Tom Gundersen
On Tue, Nov 20, 2012 at 1:07 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 Odd, my take was that the main goal was trying to bring back a
 separate /usr.

There is nothing to be done in udev for this (just have a look in the
eudev git repo; there are no commits fixing separate /usr), so that
part of the discussion is likely based on a misunderstanding.

 keeping dbus off servers.

No version of udev uses dbus, so that is not relevant.

-t


Re: [arch-general] Gentoo udev fork w/o systemd

2012-11-19 Thread Daniel Micay
On Mon, Nov 19, 2012 at 7:07 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 On Tue, 20 Nov 2012 00:54:31 +0100
 Tom Gundersen t...@jklm.no wrote:

 Having read through their discussions, it seems that the main two
 things they would like to change is to be able to build udev without
 building systemd (this does of course not change the resulting code,
 but saves time if you have to build everything locally) and to make
 the dependency on kmod optional (this might make sense if you don't
 have module support in your kernel, but I think the difference would
 not be measurable in any way).

 Odd, my take was that the main goal was trying to bring back a
 separate /usr.

 I did post to the arch-general mailing a while back about why the FSF is
 wrong on there being no need for a seperate /usr and putting everything
 in there without static core binaries in a smaller root is less
 reliable. I now wonder if that is because it was broken anyway and
 lennart gave a seemingly reasonable justification that may reduce the
 complaints.

 The other reason I noted was less dependency on upstream decisions or
 breakages and this one may have been the debian list but keeping dbus
 off servers.

The issues with a separate /usr were internal gentoo ones. Their
initramfs tool is not yet capable of mounting it, and their libkmod
package installed files to /usr (which has since been changed). That's
also the reason they removed the libkmod and libblkid support, but
since the standalone tools like modprobe still link against those
libraries there was no actual change in dependencies - just a few
hundred extra processes spawned at boot. Note that they're rolling
back those changes now, and are just going to make them optional
dependencies instead (but they will still be required, you can just
fork processes instead of calling library APIs).

They also dropped the goal of POSIX compatibility, and are just
aiming to reduce gnu-isms instead even if it means bringing back
race conditions.

Gentoo is still using udev v171, and lots of the people assumed that
they couldn't be using up-to-date udev versions without systemd as
init. However, Arch managed to do that without any trouble, so it's
another non-reason for the fork.

Also, please keep in mind that this is not (yet) an official Gentoo
project, it's just a project done by a Gentoo developer so he gets to
use their infrastructure. It is definitely not supported by all Gentoo
developers (Greg KH being one of the vocal opponents, along with
several other core developers).


Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Jude DaShiell
On Tue, 20 Nov 2012, Oon-Ee Ng wrote:

 On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen t...@jklm.no wrote:
 
  On Nov 19, 2012 10:27 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:
  
   On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens jan.steff...@gmail.com
  wrote:
  
On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng ngoonee.t...@gmail.com
  wrote:
 Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio
 output (running mpd as my own user) fails with the following:-

 Nov 19 14:45 : output: Failed to enable MPD Pulse Output [pulse]:
 pa_context_connect() has failed: Connection refused
 Nov 19 14:45 : player_thread: problems opening audio device while
  playing
 PointBreak-StandTough.mp3

 Setting up pulseaudio to listen on TCP locally as in the wiki works,
  but
I
 never needed to do that before. Can anyone else verify this? Is it
perhaps
 logind related (worked fine before this last pulseaudio update)?
   
You're running mpd from systemd? I believe it's because PulseAudio now
uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX,
$XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and
$XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie.
   
mpd has no session, so these variables are not set, unlike the session
you login to.
   
This should be sent upstream (bugs.freedesktop.org).
   
  
   Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up,
   but it's unclear to me whether 'upstream' here refers to pulseaudio,
   systemd, or mpd. Or even whether its actually wrong behaviour.
  
   My understanding of your explanation is that there's no clear
   responsibility. mpd does not use (or require) a session, the locations
   pulse uses are fairly standard (I've always hated apps using ~/.foo)...
 
  This was recently discussed:
  http://arunraghavan.net/2012/11/pulseconf-2012-report/
 
  Does not look like anything has come of it yet. I guess it might make sense
  to ask advice from the PA guys though, they would hopefully have an idea.
 
  Tom
 
 
 Thanks Tom, I'll ask on their ML.
 
 

Is 
the 
user 
that's 
supposed 
to 
be 
able 
to 
use 
mpd 
in 
the 
audio 
group? 
 
If 
not, 
it 
may 
help 
to 
add 
the 
user 
to 
audio. 
 
Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and 
mplayer until I fixed this group membership problem. 
--- 
jude jdash...@shellworld.net Adobe fiend for failing to Flash




Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Raghavendra D Prabhu

Hi,


* On Tue, Nov 20, 2012 at 07:41:52AM +0800, Oon-Ee Ng ngoonee.t...@gmail.com 
wrote:

On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen t...@jklm.no wrote:


On Nov 19, 2012 10:27 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote:

 On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens jan.steff...@gmail.com
wrote:

  On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng ngoonee.t...@gmail.com
wrote:
   Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio
   output (running mpd as my own user) fails with the following:-
  
   Nov 19 14:45 : output: Failed to enable MPD Pulse Output [pulse]:
   pa_context_connect() has failed: Connection refused
   Nov 19 14:45 : player_thread: problems opening audio device while
playing
   PointBreak-StandTough.mp3
  
   Setting up pulseaudio to listen on TCP locally as in the wiki works,
but
  I
   never needed to do that before. Can anyone else verify this? Is it
  perhaps
   logind related (worked fine before this last pulseaudio update)?
 
  You're running mpd from systemd? I believe it's because PulseAudio now
  uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX,
  $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and
  $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie.
 
  mpd has no session, so these variables are not set, unlike the session
  you login to.
 
  This should be sent upstream (bugs.freedesktop.org).
 

 Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up,
 but it's unclear to me whether 'upstream' here refers to pulseaudio,
 systemd, or mpd. Or even whether its actually wrong behaviour.

 My understanding of your explanation is that there's no clear
 responsibility. mpd does not use (or require) a session, the locations
 pulse uses are fairly standard (I've always hated apps using ~/.foo)...

This was recently discussed:
http://arunraghavan.net/2012/11/pulseconf-2012-report/

Does not look like anything has come of it yet. I guess it might make sense
to ask advice from the PA guys though, they would hopefully have an idea.

Tom



Thanks Tom, I'll ask on their ML.


Thanks for the investigation.

The only change I needed to do was add 
/run/user/1000/pulse/native (obtained from pactl info | grep 
'Server String'). I believe it may be because mpd was connecting 
or trying to connect to different server (I also noticed 
shm_unlink(/pulse-shm-2228832221) failed: No such file or 
directory in the logs and thought something wrong with 
auto-detection of mpd).



Regards,
--
Raghavendra Prabhu
GPG Id : 0xD72BE977
Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977
www: wnohang.net


pgpQoxAZwtPD0.pgp
Description: PGP signature


Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Zeke Sulastin

 Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and
 mplayer until I fixed this group membership problem.


If you're logging in with systemd, your user should definitely not be in
the 'audio' group and vlc/mplayer should be very much able to connect to
Pulse unless you have them running as their own user.  How are you starting
X?


Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user

2012-11-19 Thread Ralf Mardorf
On Mon, 2012-11-19 at 22:45 -0500, Jude DaShiell wrote:
 Is 
 the 
 user 
 that's 
 supposed 
 to 
 be 
 able 
 to 
 use 
 mpd 
 in 
 the 
 audio 
 group? 
  
 If 
 not, 
 it 
 may 
 help 
 to 
 add 
 the 
 user 
 to 
 audio. 
  
 Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and 
 mplayer until I fixed this group membership problem.

The link in the original mail does provide a link that says: Don’t add
your user to the “audio” group -
http://voices.canonical.com/david.henningsson/

Regards,
Ralf