Re: http://lists.debian.org/ list index split up

2001-08-15 Thread Steve M. Robbins
On Wed, Aug 15, 2001 at 11:05:58PM +0200, Josip Rodin wrote: > Hi, > > The index on http://lists.debian.org/ has been split up in subcategories, > and stuff. > > A lot of people wanted this, hope you're happy now :) So far, I like it. Before this, I didn't realise that there were so many mail

Bug#108958: listarchives: lcs-eng is nothing but spam

2001-08-16 Thread Steve M . Robbins
Date: Thu, 16 Aug 2001 08:33:57 +0200 To: "Steve M. Robbins" <[EMAIL PROTECTED]> Cc: debian-www@lists.debian.org, debian-devel@lists.debian.org Subject: Re: http://lists.debian.org/ list index split up From: Josip Rodin <[EMAIL PROTECTED]> On Wed, Aug 15, 2001 at 09:42:24PM -

Bug#117479: [james@nocrew.org: Bug#117418: napshare_0.1-2(unstable/ia64): fails to compile from source on 64 bit platforms]

2001-10-28 Thread Steve M. Robbins
Package: www.debian.org Severity: normal Please remove napshare from the repository (unstable and testing; it was never in stable). In light of the report that napshare has build problems, and given that napshare upstream is dormant whereas the upstream of gtk-gnutella (from which napshare is a f

stalled updates?

2002-09-21 Thread Steve M. Robbins
Howdy, The last update for both debian-devel and debian-gtk-gnome was on Thursday morning, over 48 hours ago. I think it is normally more frequent than that. Does something need attention? Thanks, -S

Re: Add contact info for buildd maintainers

2008-09-22 Thread Steve M. Robbins
On Mon, Sep 22, 2008 at 02:52:35PM +0200, Josip Rodin wrote: > On Mon, Sep 22, 2008 at 02:44:41AM -0500, Steven Robbins wrote: > > Somewhere on http://www.debian.org/devel/buildd/ there needs to > > be info about contacting the buildd admins. I eventually found > > it buried (on http://www.debian.

python policy manual not reliable

2009-03-08 Thread Steve M. Robbins
On Sun, Mar 08, 2009 at 05:27:33AM +0100, Josselin Mouette wrote: > Le samedi 07 mars 2009 ? 22:17 -0600, Steve M. Robbins a ?crit : > > OK. I'm certainly in favour of avoiding complexity. However, I > > thought I was following the python policy [1] where B.1 says: &