Who does a developer have to fuck around here to get his key deleted?
--
Chip Salzenberg <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, Nov 11, 2005 at 03:09:22PM +0100, Wouter Verhelst wrote:
> Op do, 10-11-2005 te 16:22 -0800, schreef Chip Salzenberg:
> > Bill Allombert <[EMAIL PROTECTED]> writes:
> > > There are around 1000 developers out there. At the very least I am
> > > sure you woul
On Fri, Nov 11, 2005 at 12:48:14AM +, Martin Michlmayr wrote:
> * Chip Salzenberg <[EMAIL PROTECTED]> [2005-11-10 16:22]:
> > Since I sent my resignation mail, I have been told that the keyring
> > was updated twice after my initial request for key change. Why was my
&
for other people, not trolling for sponsors.
Since I sent my resignation mail, I have been told that the keyring
was updated twice after my initial request for key change. Why was my
key not added? No reason has been presented, publically or privately.
--
Chip Salzenberg <[EMAIL PROTECT
libyaml-perl
--
Chip Salzenberg <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Package: wnpp
Severity: important
I have orphaned the source package nfs-utils (binary packages
nfs-common, nfs-kernel-server, and nhfsstone). I've recently added
other open source development responsibilities (the Parrot project),
and the NFS code needs someone who can give it more concentrated
According to Will Lowe:
> According to http://db.debian.org/machines.cgi, you can get an
> account on kullervo.debian.org.
I hadn't thought to look there. Silly me.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch
According to Ben Collins:
> On Thu, Mar 30, 2000 at 11:12:27AM -0800, Chip Salzenberg wrote:
> > May I assume that the latter two bugs will not delay the release of
> > potato for i386?
>
> Couldn't be more wrong. Bugs are bugs...a package with a serious bug on a
>
on non-i386 architectures
May I assume that the latter two bugs will not delay the release of
potato for i386?
> Package: pdl (debian/main).
> Maintainer: Raul Miller <[EMAIL PROTECTED]>
> 55268 [Strategy: use older version on alpha] PDL fails to compile on alpha
Likewise?
I am coming from.
Oh, you're entirely right. People _are_ too tied up in 'freedom' to
focus on the software. But that's because, as a body, the Debian
project is all about freedom, as _expressed_ in software (and other
things, too).
You want pragmatism? Work with FreeBSD.
According to Josip Rodin:
> They can't both be standard if they conflict with each other, see Policy.
Well, then, don't remove one, just change its priority!
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the
According to Christian Hammers:
> According to the automated report:
> > Package: nfs-kernel-server (debian/main)
> > Maintainer: Chip Salzenberg <[EMAIL PROTECTED]>
> > 59641 nfs-kernel-server: conflicts with Standard package nfs-server
> > Package: nfs-se
According to Michael Alan Dorman:
> Chip Salzenberg <[EMAIL PROTECTED]> writes:
> > [2] Debian doesn't create this specific hard link, but it should.
> > For example, my system has "/usr/bin/perl5.00503".
>
> Well, we do have perl-5.X, sans subversion
warnings or else with absolute
version paths ("#!/usr/bin/perl5.005"). [2]
[2] Debian doesn't create this specific hard link, but it should.
For example, my system has "/usr/bin/perl5.00503".
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"When do you work?" "Whenever I'm not busy."
;t get me wrong; as the father (or at least midwife) of Perl 5.004,
I think it's a great program. But 5.005 has much to recommend it, too.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"When do you work?" "Whenever I'm not busy."
nderdeveloped
and buggy" is the threading. So I wouldn't suggest that Debian's
default Perl have threading enabled. Otherwise, though, 5.005 is
plenty stable -- it's on its third maintenance patch.
All IMO, of course. But I am one of the core Perl developers, so my
opinion is
According to Jules Bean:
> On Sun, 31 Jan 1999, Chip Salzenberg wrote:
> > Consider that I may wish to mount a filesystem nosuid for the purpose
> > of making a tape backup. Would I want the suid bits turned off in the
> > backup image? I think not.
>
> Why not just
According to Jules Bean:
> On Sun, 31 Jan 1999, Chip Salzenberg wrote:
> > Every OS has a different set of mount options that may or may not be
> > relevant to setuid security. I don't see what 'higher level' would be
> > useful.
>
> The correct solutio
According to Jules Bean:
> On Sun, 31 Jan 1999, Chip Salzenberg wrote:
> > The code exists to check the mount options relevant to an open file.
> > It's just a Small Matter of Programming to integrate that into the
> > Perl source code, and disable emultation of setuid sc
According to Michael Stone:
> Quoting Chip Salzenberg ([EMAIL PROTECTED]):
> > According to Michael Stone:
> > > Quoting Wichert Akkerman ([EMAIL PROTECTED]):
> > > > What perl-suid should do is check the mountoptions for the filesystem on
> > > > whic
ut that's still not general enough. For example, you just missed the
> case of noexec... The solution should be done at a higher level, IMHO...
Every OS has a different set of mount options that may or may not be
relevant to setuid security. I don't see what 'higher level'
21 matches
Mail list logo
