I am still on the keyring. With my old key.
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]
Re: Resignation and uploads
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 would find several of them willing to sponsor your upload. > > > > That's not a fix, it's a bad workaround. > > Yes, but one that works. No. A workaround that works would be a *good* one. This is a *bad* one. It doesn't scale, for one thing. Else, why even have DDs? Just have random people send source packages to one guy with The Debian Key. And for me to update my contact info or change my ssh key, there is no substitute for a key on the keyring. > Stop whining, please. *grin* Stop trying to suppress negative commentary, please. -- Chip Salzenberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
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 > > key not added? No reason has been presented, publically or privately. > > Did you follow http://keyring.debian.org/replacing_keys.html ? Yes. -- Chip Salzenberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resignation and uploads
Bill Allombert <[EMAIL PROTECTED]> writes: > There are around 1000 developers out there. At the very least I am > sure you would find several of them willing to sponsor your upload. That's not a fix, it's a bad workaround. I was a DD. I should have been sponsoring uploads 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 PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resignation and orphan list
Having lost my access to my old GPG key, I followed project procedure for creating and validating a new one. The final step is a signed request to [EMAIL PROTECTED] That request was sent on October 3. However, my new key is still not on the keyring. James Troup (elmo) is the only human behind [EMAIL PROTECTED] Over the past five weeks, Mr. Troup has found lots of time to participate in Ubuntu development, as evidenced by his continued activity on the #ubunto-devel IRC channel. However, despite many requests by mail and IRC, he has not found five minutes to update the keyring with my new key. Branden Robinson, the DPL, is aware of this organizational failure. But he has done nothing effective to repair it. He has suggested that another DD, Jeroen van Wolffelaar, has the authority to make keyring changes -- an odd situation, given the [EMAIL PROTECTED] alias, but no matter -- but Mr. van Wolffelaar has made no more progress than Mr. Troup has: that is to say, none. I see no point in trying to force my way (back) into a project that shows no interest in allowing me to keep participating. Therefore, I hereby resign from the Debian Project. My resignation orphans the following packages: deliver libclass-factory-perl libclass-inner-perl libcss-tiny-perl libextutils-cbuilder-perl libextutils-parsexs-perl libhttp-server-simple-perl liblist-moreutils-perl libmail-spf-query-perl libmodule-signature-perl libnet-cidr-lite-perl libnet-ftpserver-perl libpadwalker-perl libppi-html-perl libppi-perl libppi-xs-perl libproc-background-perl libstring-koremutake-perl libsys-hostname-long-perl libterm-size-perl libyaml-perl -- Chip Salzenberg <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#303559: O: nfs-utils -- NFS support files common to client and server
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 engineering attention. The package description is: Use this package on any machine that does NFS either as client or server. Programs included: lockd, statd, showmount, and nfsstat. . Upstream: SourceForge project "nfs", CVS module nfs-utils. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11.6 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (Bug horizon) Problem bugs
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 with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: (Bug horizon) Problem bugs
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 > supported arch, affects that package period, no matter what arch you are > talking about. But that makes no sense ... I'm a Debian developer, but I have no access to any m68k machines. Yet potato, which includes some of my work, can't be released ... and I can do nothing about it? Feh. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: (Bug horizon) Problem bugs
According to Richard Braakman: > Package: gcc (debian/main). > Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> > 58412 r-base: Can't build from source > 59819 gcc_2.95.2-7(frozen): fails to compile itself on m68k > 61258 missing header files in include/asm 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? -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Not to get off on a rant here.....
According to Franklin Belew: > Hi, you may know me from such irc channels as #debian and #debian-devel > as Myth. I'm Troy McClure! Er, no, that's not right. > These may sound like the disgruntled ramblings of a frustrated wannabe > developer, but I hope you can see where 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. No flame, no smiley. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Release-critical Bugreport for March 10, 2000
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 impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Release-critical Bugreport for March 10, 2000
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-server (debian/main) > > Maintainer: Herbert Xu <[EMAIL PROTECTED]> > > 59642 nfs-server: conflicts with Standard package nfs-kernel-server > > Huh? Isn't this what it is expected to? Yes, that's expected. I thought those bugs had been downgraded. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: problems with the perl5 packages
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. That's good, but it breaks the upstream pattern of "perl#.###". So I guess all I'd like to see is the deletion of that hyphen. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: problems with the perl5 packages
According to Dale Scheetz:
> Are there any circumstances where perl-5.004 is compatible with earlier
> version like perl-4?
Most Perl 4 programs still work fine with any version of Perl 5. But
there were a couple of language changes between Perl 4 and Perl 5 that
actually make programs fail (but loudly -- no silent failures).
> I can only assume that [...] perl-5.004 is not backward compatible
> with the previous version?
All versions of Perl 5 are compatible with earlier versions of Perl 5
at the source code level -- i.e. Perl programs should work fine after
upgrades. [1]
If compiled with the default options, 5.004 is even binary-compatible
with extensions that were built for Perl 5.003. But most versions
don't retain binary compatiblity for extensions.
[1] However, each version can add new warnings, so we encourage users
to install production code without 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."
Re: Perl 5.005 features
According to Michael Stone:
> The only thing [new in Perl 5.005] I've heard so far is threading,
> which AFAIK is too unstable to be in stable.
Agreed about threading.
But the list of New Stuff also includes:
* References as thrown exceptions ('die $object', '[EMAIL PROTECTED]>method')
* Pseudo-hashes (fast hash-like behavior from arrays)
* Closely related to the above: 'use fields' pragma
* Significantly smarter regexes and the qr// quoting mechanism
* Global keyword overriding with CORE::GLOBAL::keyword
* Tied arrays are complete; tied handles are more complete
* $/ can be used for fixed-length records ('$/ = \80')
And some guts things:
* More robust embedding support (for e.g. mod_perl)
* Numerous core dump bugs fixed, largely through the internal
feature known as "stack of stacks"
Don'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."
Re: Perl 5.005 stability
According to Aaron Van Couwenberghe: > On Sun, May 09, 1999 at 08:14:24PM -0700, Jim Lynch wrote: > > This means that upgrading perl (whenever it is done) will need the same > > degree > > of care applied as for dpkg, dselect, boot-floppies, debian-cd and all other > > essential parts of debian infrastructure, and -not- that of "just another > > app". > > You forget to mention some important points -- those new features in perl > 5.005 are both underdeveloped and buggy. The only part of Perl 5.005 that could be described as "underdeveloped 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 at least educated. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: suid-perl
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 mount it somewhere only you can get at it? Touche'. I concede. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: suid-perl
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 solution to this, surely, is for the mount nosuid to actually > strip the suid bits of any files. So that any calls to stat() on a floppy > simply won't see suid bits. I can see it both ways. 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. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: suid-perl
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 scripts when the > > 'nosuid' mount option is set. > > But, then every interpreter should do this [...] every suid-emulating > interpreter. (For those who don't know, suidperl is a setuid root binary that securely *emulates* setuid scripts on operating systems that don't support them directly.) And yes, in theory, other suid-emulating interpreters ought to do the same checks -- but AFAIK, there _are_ no others. > Why hasn't linus patched the kernel so that suid scripts are secure? > It's an easy task, surely? "Beats the heck out of me, Batman." > As it is, noexec is almost useless. I can't help thinking that > *all* interpreters *should* check noexec status. What's the point? Such files can be copied to /tmp and run there -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: suid-perl
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 > > > > which the script resides and abort if that was mounted with nosuid. > > > > Should be quite simple actually.. > > > > > > But 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' would be > > useful. > > Well, maybe I'm not clear on what you/wichert would do instead. How are > you going to check this? 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 scripts when the 'nosuid' mount option is set. And as for 'noexec', well, it's not relevant to Perl anyway. (All you have to do is run "perl scriptname" instead of just "./scriptname".) Or do you suggest that every single language compiler/interpreter must check mount options? Should Java .class files be unusable if they're on a 'noexec' filesystem? I don't _think_ so. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
Re: suid-perl
According to Michael Stone: > Quoting Wichert Akkerman ([EMAIL PROTECTED]): > > What perl-suid should do is check the mountoptions for the filesystem on > > which the script resides and abort if that was mounted with nosuid. > > Should be quite simple actually.. > > But 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' would be useful. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "When do you work?" "Whenever I'm not busy."
