[gentoo-amd64] Re: Re: arts

[Duncan]

Benny Pedersen posted
<48612.80.166.75.19.1120990641.squirrel@×××××××××.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
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list