From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Re: arts
Date: Sun, 10 Jul 2005 04:50:23 -0700 [thread overview]
Message-ID: <pan.2005.07.10.11.50.20.234367@cox.net> (raw)
In-Reply-To: 48612.80.166.75.19.1120990641.squirrel@mail.junc.org
Benny Pedersen posted
<48612.80.166.75.19.1120990641.squirrel@mail.junc.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@gentoo.org mailing list
prev parent reply other threads:[~2005-07-10 11:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-08 3:23 [gentoo-amd64] arts Benny Pedersen
2005-07-08 3:42 ` Zac Medico
2005-07-08 9:21 ` [gentoo-amd64] arts Duncan
2005-07-08 10:57 ` Peter Humphrey
2005-07-08 11:17 ` Tres Melton
2005-07-08 11:46 ` Peter Humphrey
2005-07-08 23:10 ` Alexey Maslennikov
2005-07-09 1:00 ` [gentoo-amd64] " Duncan
2005-07-09 2:37 ` [gentoo-amd64] " Luigi Pinna
2005-07-09 9:40 ` Alexey Maslennikov
2005-07-09 11:22 ` [gentoo-amd64] arts Luigi Pinna
2005-07-09 12:01 ` [gentoo-amd64] arts Duncan
2005-07-11 16:04 ` Luigi Pinna
2005-07-11 17:44 ` Alexey Maslennikov
2005-07-12 11:16 ` [gentoo-amd64] " Duncan
2005-07-09 10:15 ` Duncan
2005-07-10 10:17 ` [gentoo-amd64] " Benny Pedersen
2005-07-10 11:50 ` Duncan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2005.07.10.11.50.20.234367@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox