Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: arts
Date: Sun, 10 Jul 2005 11:52:33
In Reply to: Re: [gentoo-amd64] Re: arts by Benny Pedersen
Benny Pedersen posted
<48612.×××××××××.org>, excerpted below, 
on Sun, 10 Jul 2005 12:17:21 +0200:

> On Fri, July 8, 2005 11:21, Duncan wrote: > >> Expanding on what Zac said, ensure your user is in the audio group, and >> that udev is set up to use that group for audio devices and that the mode >> is 660. > > that was the pointer for me[3], i have disabled arts and enabled alsa olso > in the kernel after that rebuild all that hasuse arts[1] in use settings, > and last emerged all alså supporting tools[2], wonderfull it sound is > again working on my asus sk8n
LOL! I've never used the usermod tool. I always simply edit the /etc/group or /etc/passwd files directly (yes, I know about the possible race conditions, but if I'm the only human user and I'm not in the middle of an emerge or something else that might try to edit the files...). I'm used to loading them to grab a quick look at what users are on what groups, as well. BTW, all you would have needed to do (and you still might want to, to catch any other changes you may have missed) is run emerge --ask --newuse --verbose (-aNv), and portage would have figured out what packages were emerged with outdated flags and asked you if you wanted to remerge them. The --newuse (-N) flag is one of the quite useful newer features in the portage 2.0.51 series, so if you didn't know about it, take a look at the emerge man page and note that flag for further reference.
>> Also, check your PAM settings, console.perms IIRC. Gentoo is moving away >> from using the PAM console-perms module by default, because it causes > > will pam still be an problem for me now when the silence is dead here ?
It may not be, but it'a /always/ a useful thing to keep in the back of your mind to check, if for some reason you appear to be having permission problems, particularly if it seems to work sometimes and not others (altho it's entirely possible you only see the "fail" condition, if you never satisfy the conditions that would trigger "success" in your normal routine), because PAM has a number of features that can be used to dynamically control permissions. It's also useful to keep PAM in mind for that dynamic permission control feature, just in case you sometime need to control access to something by time of day, or some other such strange thing. (A caveat with the time of day thing -- there's a sort of bypass ability if you don't set it up right, for those smart enough to figure it out, so don't count on something like that to be 100% foolproof, at least not without reading the PAM documentation, which explains the issue quite well. It works well in the same fashion a padlock does, however. Most padlocks are easily snipped in seconds with a bolt cutter, many easily knocked open with just the right tap from a hammer, but they serve as an indicator of intended lack of permission, and as they say, to "keep the honest people honest", even if everyone knows they aren't really all that secure if one's intent is to get at what they are "protecting".)
> using kernel 2.6.12 r4 now
Hmm... I haven't the foggiest what Gentoo's kernel ebuilds are like, as I learned how to download and build my own kernel relatively quickly after switching from MSWormOS (within 90 days), and had been doing it on Mandrake for some time before switching to Gentoo, so saw no reason at all to change that, so didn't.
> [1] equery hasuse arts > [2] equery hasuse alsa > emerge from the listning above > [3] usermod -G audio myuser
-- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in -- gentoo-amd64@g.o mailing list