It seems to be impossible for normal users to run programs, alsaplayer, mplayer, etc. which access normal audio devices in recent releases of Gentoo Linux. The devices are no longer rw by the audio group (as was previously the common practice) so all previously designed group permissions now fail. A "released version of Linux" should not "break" practices so as to defeat users of such a release. That implies an implementation of testing that which has gone before still works. Thus there are no "break" points or at least they are well known up front. Gentoo should make extreme efforts to inform when standard audio practices will be broken by upgrades. Reproducible: Always Steps to Reproduce: 1. Play music by a non-privileged user before ~Mar 2010. 2. Play music after ~Mar 2010. 3. Playing music in an up-to-date Gentoo distribution fails. Actual Results: Playing music as well as logins by new users to GDM should *always* work! I,e. Gentoo "upgrades" should always ascertain that they do not "break" user use of a gnome framework. In that respect recent Gentoo upgrades fail. I cannot play audio and I cannot create a new "gnome" desktop login -- even though old logins continue to work. Expected Results: The playing of sound or the creation of new login-ids should *always* work as desktops are upgraded. Gentoo seems to have a problem doing sufficient Q&A in those areas.
Created attachment 240905 [details] emerge --info emerge --info. The primary problem here appears to be that udev creation of sound devices is not granting group access to the audio group.
Can you kindly explain what a "release version of Gentoo Linux" is ? Can you also provide *technical details* related to your problem please (udev version, kernel sources and version, ls of /dev/dsp, groups layouts, sound system settings, etc) ? Please read Bug submitting guidelines if necessary.
I consider a "release" version of Gentoo Linux to be one where the kernel sources have the "-gentoo" nom de jour (as vs. the git-sources kernel sources which appear to be straight from the kernel developers). However, as pertains to this bug, the problem does not appear to be in the kernel per se. I can play music using alsaplayer on the machine -- but *only* as "root". The installed version of udev is udev-160. I had a similar problem several years ago and fixing it involved adding the users to the "audio" group. The system boot process defaulted to setting up the sound devices to be mode 660, owned by root:audio. That is no longer true. The primary audio device (/dev/dsp) is mode 600, owned root:root. So having the users as members of the audio group is no longer sufficient to access the sound devices. Generally speaking all installed packages are running on the bleeding edge (i.e. commented ~x86 in /etc/portage/package.keywords). Looking back an old saved root device it would appear that circa 2008 there was a file /etc/udev/rules.d/65-permissions.rules, there was also a 40-alsa.rules. Though I have not looked at them in detail a surface examination suggests that they may be the source of setting up the ownership/permissions of the audio devices. Neither of these files exists in the root of my current system and I have no recollection of deleting them. I do have /etc/udev/rules.d with 23 files in it but none of them appear to involve setting up "audio" group ownership or permissions on the sound devices.
(In reply to comment #3) > I consider a "release" version of Gentoo Linux to be one where the kernel > sources have the "-gentoo" nom de jour (as vs. the git-sources kernel sources > which appear to be straight from the kernel developers). Gentoo Linux as a distribution being a rolling release model, the notion of release is quite blurry. Anyway. You are right, for the sound sub-system to be usable by unprivileged users, the /dev/dsp device node should be chmod'ed 0660 and root:audio owned (as most of the files under /dev/snd/). This is normally the case, even on the latest/bleeding edge/whatever versions of udev and with whatever "standard" kernel sources from portage (and AFAIK, there is no alsa related patches in the latests sys-kernel/gentoo-sources versions in portage. Things have changed since 2008. The rules shipped with udev itself are in: /lib/udev/rules.d/ (and you will find here several rules responsible of setting the right perm and u/g on /dev/dsp. This rules as been proven to work out-of-the-box the vast majority of Gentoo users. I would advise closing that bug as INVALID from now (you can do it), and open a topic with all relevant details on f.g.o, in the Multimedia category. Once a bug as been clearly found, you might want to reopen the present bug report.
Posted after detecting mid-air collision: It would appear that 65-permissions.rules was a component in udev-119 thru udev-124 active from Apr 2008 thru Aug 2008. I can find no record of when or how it was removed. I generally keep the output of all emerges so I can search through them to see when files were installed or removed. Only in rare instances where there is a blocking emerge would I have unmerged a udev package to install a new one and I do have a record of or recall doing that. The questions would remain as to why 65-permissions.rules no longer seems to be part of udev and/or what "replaced" it to properly setup the ownership and permissions on the installed sound devices. Another way of asking this question is "How does a non-privileged user access sound devices on a current Gentoo install?" The question remains after reading Gef's comment #4... What specific file in "current" releases sets the ownership/modes on sound device(s)? Subsequent to that would be the question of "Are udev releases are 'atomic'?", i.e. does udev always install *all* the files needed to create a working system? If not then do I need to go back and install udev-124 and subsequently udev-160 to get a functional up-to-date system? I'll be happy to close out the bug once we nail down what specific file(s) is/are required and the sequence of emerges required to install it/them.
Actually, it's only a part of the truth about current situation. This is a result of two things: - recently udev upstream removed (nearly (?)) all distro-specific rules - systems using ConsoleKit are preferred; in such case active session gets audio devices via acl udev rules As for the later, about every month there's a bit of bike-shedding on the topic i.e. on pulseaudio mailing list. Also, IIRC, main sound provider for linux is ALSA, so /dev/dsp isn't really *primary* audio device.
