Patrick Lauer wrote: > On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
>> Again, read what I wrote. I said that the developer would see "sunrise" >> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated >> without considering. This is a login bug. At no point did they make >> mention of having installed pam_skey from this overlay. This means that >> I, as the developer getting this bug, am now responsible for looking at >> *every package* in the sunrise overlay to determine if *any* of them >> could *possibly* be affecting this package or causing this bug, then >> asking the user if they have any of them installed. > This differs from a manually patched ebuild in /usr/portage by virtue of > showing you that an overlay is used ... > >> Wouldn't this process be *infinitely* easier if instead of "sunrise" >> there was a "pam" overlay with *only* the pam stuff? > Ooooh, cool. Now I need about 75 overlays to get things done, and of course > there will be no bad interaction between them ;-) Please, leave pam_skey alone. ;) It's a thing I'm using daily and the default system-auth config file installed by this ebuild allows for both system and S/KEY passwords to be used at the same time, you can pick whichever one you want. There's no way to get yourself locked out of system unless you've already forgotten your normal password and didn't yet set up OTP, in which case, it's not pam_skey problem at all. The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond "it compiles and installs" is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. > Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. >> This is a prime example of totally glossing over any discussion to make >> it sound promising for you. > If bugzilla wasn't so sucky people wouldn't try to use other methods of > communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;)
signature.asc
Description: OpenPGP digital signature
