* Holger Levsen [250102 13:03]:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> > I'm wondering how we can clean up suites like experimental and
> > unstable. They tend to slowly accumulate cruft that nobody cleans up,
> > including no longer installable packages.
>
> for experiment
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
for experimental: yes, please!
for unstable: what Helmut sa
* Andreas Metzler [241231 06:59]:
> On 2024-12-29 Helmut Grohne wrote:
> > On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> [...]
> >> I would also like to do something similar to unstable; maybe start with
> >> packages uploaded before some arbitrary date that are also not included
>
On 2024-12-29 Helmut Grohne wrote:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
[...]
>> I would also like to do something similar to unstable; maybe start with
>> packages uploaded before some arbitrary date that are also not included
>> in any of oldstable/stable/testing. These ca
Le Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 a écrit :
> Hi,
>
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to rem
Hi Ansgar,
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to rem
Ansgar dixit:
> musescore-snapshot| 2019-07-05 00:19:11.735843+00
I do have plans to pick that up once I find the tuits for it
and have finished the preceding musescore{2,3} uploads. (Lots
to do there.) So please keep that for now.
Thanks,
//mirabilos
--
[16:04:33] bkix: "veni
Hi,
On 29/12/2024 13:08, Ansgar 🐱 wrote:
[…]
As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).
Yes please.
> David Prévot
>php-sabre-event (U)
>php-sabre-
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to remove packages
Date: Sun, 29 Dec 2024 13:37:50 +0100
From: Matthias Geiger
To: ,
Cc:
Bcc:
Subject: Re: Remove ancient uploads from experimental (and later
unstable)
In-Reply-To: <87ikr2zo6m@43-1.org>
Hi,
As a very simple start, I would like to remove packages from
experimental that haven
Quoting Scott Kitterman (2021-12-06 16:03:31)
> Speaking only for myself here, not the team as a whole:
>
> The tools we use default to age order, so if one just starts working
> through packages in the order given, it's oldest first. Personally, I
> rather rarely do that. I don't have a lot o
On Monday, December 6, 2021 8:58:15 AM EST Andreas Tille wrote:
> Hi Jonas,
>
> I've thought that it is probably not my turn to answer your questions
> but since there was no answer yet I'd like to report from my experience.
>
> Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:
>
Hi Jonas,
I've thought that it is probably not my turn to answer your questions
but since there was no answer yet I'd like to report from my experience.
Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:
>
> Is "Age" used to rank processing of NEW requests?
I have some evidence
Quoting Johannes Schauer Marin Rodrigues (2021-11-18 11:26:44)
> Quoting Tobias Frost (2021-11-18 10:38:40)
> > (speculatinng on the why you want it rejected: if you want to replace it
> > with e.g. a newer version, you can just upload the new version)
>
> slightly related question: if I upload a
Quoting Tobias Frost (2021-11-18 10:38:40)
> (speculatinng on the why you want it rejected: if you want to replace it with
> e.g. a newer version, you can just upload the new version)
slightly related question: if I upload a new version to NEW, will the Age of
the package be reset? I'm asking bec
Am 18. November 2021 10:30:37 MEZ schrieb Stephan Lachnit
:
>I tried to remove a package from NEW with `dcut rm package.deb`, `dcut
>rm package.changes` and `dcut cancel package.changes`, but nothing
>worked.
>Is there even a way to remove a package from NEW?
>
>Regards,
>Stephan
>
ask FTP Master
Processing control commands:
> reassign -1 general
Bug #822538 [debian-maintainers] debian-maintainers: Remove character (%) from
alls packages name
Bug reassigned from package 'debian-maintainers' to 'general'.
Ignoring request to alter found versions of bug #822538 to the same values
previous
On Wed, 6 Apr 2016, Marco d'Itri wrote:
[...]
> > A year ago a user also mentioned that there is a new upstream version
> I have some doubts about the quality of this fork, so I plan to
> investigate in detail what has changed before blindly adopting it.
What about uploading a new version with t
On Wed, Apr 6, 2016 at 3:47 PM, Mathieu Parent wrote:
> 2016-04-06 6:55 GMT+02:00 Paul Wise:
>> Personally I am still waiting for clamav freshclam to properly support
>> third-party signatures, so clamav-unofficial-sigs can be a config file.
>
> Is there a tracking bug for this? How can we help?
T
2016-04-06 6:55 GMT+02:00 Paul Wise :
> On Wed, 2016-04-06 at 00:35 +0200, Marco d'Itri wrote:
I didn't knew about those third-party signatures. This is a good news for me.
>> I was discussing this yeasterday with Paul.
>> While the current package has some issues I believe that it is already
>>
On Wed, 2016-04-06 at 00:35 +0200, Marco d'Itri wrote:
> I was discussing this yeasterday with Paul.
> While the current package has some issues I believe that it is already
> quite useful as is, so if the alternative is to remove it from the
> archive then I am going to adopt it.
It would be g
On Apr 05, Francois Gouget wrote:
> clamav-unofficial-sigs is broken and not maintained anymore. So unless
> something changes there is no point leaving it in the repository.
I was discussing this yeasterday with Paul.
While the current package has some issues I believe that it is already
quite
Hi,
Giacomo A. Catenazzi wrote:
>>> I think that as long as the package (cdgrab, in this case) is
>>> not longer in stable, the conflicts line may be removed (we support
>>> partial upgrades from stable, as far as is possible). In this case,
>>> apparently cdgrab is not anywhere, so th
Giacomo A. Catenazzi wrote:
Manoj Srivastava wrote:
On Wed, Aug 12 2009, Timur Birsh wrote:
Hello Debian Developers,
I've recently uploaded (thanks to Bart Martens for sponsoring) my
first package and want to adopt the next one. It's cd-discid [1]. Its
debian/control file contains the Confl
Manoj Srivastava wrote:
On Wed, Aug 12 2009, Timur Birsh wrote:
Hello Debian Developers,
I've recently uploaded (thanks to Bart Martens for sponsoring) my first
package and want to adopt the next one. It's cd-discid [1]. Its
debian/control file contains the Conflicts field. This package conf
On Wed, Aug 12 2009, Timur Birsh wrote:
> Hello Debian Developers,
>
> I've recently uploaded (thanks to Bart Martens for sponsoring) my first
> package and want to adopt the next one. It's cd-discid [1]. Its
> debian/control file contains the Conflicts field. This package conflicts
> with cdgr
On Tue, May 5, 2009 at 4:51 PM, Neil Williams wrote:
>
> > Is there any way to remove some package from debian distribution? For
> > example: package bcrypt is completely dead. It doesn't work at amd64
> > at all because of obvious bug, which I've reported here (path
> > included) half a year ago
On Wed, 6 May 2009 03:34:12 +0700
Alexey Salmin wrote:
CC'ing the maintainer.
> Hello! At first I want to say that I'm not sure that this mailing list
> is a right place for my letter. Secondly, this letter isn't actually
> about some specific package, I'm just interested in understanding
> Deba
On Wed, May 06, 2009 at 03:34:12AM +0700, Alexey Salmin wrote:
> Hello!
Hi!
> At first I want to say that I'm not sure that this mailing list
> is a right place for my letter. Secondly, this letter isn't actually
> about some specific package, I'm just interested in understanding
> Debain polici
I think it's time for libflash to go, yes.
William
On Sat, 2008-08-23 at 22:13 +0900, Nobuhiro Iwamatsu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi, All.
>
> I am maintainer of libflash[0] pakcage.
>
> This package is very old. and only an old Flash version is supported.
>
On Fri, Aug 18, 2006 at 01:24:06PM -0500, Steve Greenland wrote:
> No sign of what it actually did, no sign of whether the answer was
> yes or no. Yes, there is some stuff in there. But not always enough.
> Sometimes it spits out what the compile command was, and the code used,
> and sometimes it
On 17-Aug-06, 23:33 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> [Steve Greenland]
> > By "autoconf related problems" I mean things like it suddenly
> > deciding it's running a cross compiler, or that stdlib.h is
> > missing. A lot of this kind of stuff could be improved by simply
> > SH
I demand that Russ Allbery may or may not have written...
> Steve Greenland <[EMAIL PROTECTED]> writes:
>> And, for example, all of a sudden (autoconf 2.5, I think) every/many
>> (newly generated or regenerated) configure script starting checking for
>> C++ compilers, Fortran compilers, etc. etc.
On Friday 18 August 2006 06:56, Matthew R. Dempsky wrote:
> On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
> > So are some widespread programming languages. If you blindly follow bad
> > examples and bad styles you can dynamite yourself happily without even
> > noticing, but that d
[Steve Greenland]
> By "autoconf related problems" I mean things like it suddenly
> deciding it's running a cross compiler, or that stdlib.h is
> missing. A lot of this kind of stuff could be improved by simply
> SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
> return code an
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
> So are some widespread programming languages. If you blindly follow bad
> examples and bad styles you can dynamite yourself happily without even
> noticing, but that does not make them disused or abandoned (on the contrary
> some
[Wouter Verhelst]
> It has nothing to do with "being afraid to", but everything with "not
> needing to".
There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation. I believe that building a package
from source is something we should do as well, if on
On Thursday 17 August 2006 19:02, Steve Greenland wrote:
> On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
> > As for useless autoconf tests - have you looked at how autoconf is
> > used? You pick the tests you think you need. It's not like the system
> > forces you to use a
Steve Greenland <[EMAIL PROTECTED]> writes:
> And, for example, all of a sudden (autoconf 2.5, I think) every/many
> (newly generated or regenerated) configure script starting checking for
> C++ compilers, Fortran compilers, etc. etc. etc. even for pure C
> projects.
This is a libtool bug.
--
R
On 17-Aug-06, 09:06 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On the other hand, sw with custom build systems were always a pain:
> usually they had no idea how to build a shared lib on AIX,
Neither does libtool. But I can usually easily change the Makefile to
fix that problem; libtool is
On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> As for useless autoconf tests - have you looked at how autoconf is
> used? You pick the tests you think you need. It's not like the system
> forces you to use a certain range of obsolete baseline tests. A huge
> number o
Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote:
>> Yeah, wanting to use functionality when it's available is always a
>> dreadful idea. Far better to reimplement it locally in order to ensure
>> that we have more copies of it to
On 16-Aug-06, 20:23 (CDT), Miles Bader <[EMAIL PROTECTED]> wrote:
> The main problem with your argument is that you seem to be looking at
> poorly written programs that use autoconf, and jumping to the conclusion
> that autoconf is the reason for the poor programming -- it's not. Bad
> programmer
On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote:
> Yeah, wanting to use functionality when it's available is always a
> dreadful idea. Far better to reimplement it locally in order to ensure
> that we have more copies of it to fix should there ever be any sort of
> security
On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote:
> So you chose to use a function not reliably available. Sounds like bad
> planning to me.
More than a year ago the plan was that we'll support Debian Sarge only.
Then a couple of weeks ago our project partner said they'll be using
On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
> [Michael Poole]
> > On top of the default automake behavior being horribly broken, does
> > that make usual revision control practices horribly broken?
>
> It really bothers me to hear people claim as a best practice that you
> sho
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
>>
>> > And guess what? System tests are actually more reliable, especially
>> > when the user tells you what the s
[Steve Greenland]
> My experience is that the ones whose build instructions say "edit the
> makefile to pick your platform and compiler" compile and work, and
> when they don't, they're easy to fix. The ones that use autoconf tend
> to blow up on non-Linux[1], in ways that are hard to debug and da
Steve Greenland <[EMAIL PROTECTED]> writes:
> You figure out where the incompatability points are, and you write
> functions to mask them. Of course the functions themselves have
> #ifdefs (or some other way of controlling compilation), but you get it
> *out* of your main code base.
Gee sounds lik
Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
>> This will never work. Real life example from a couple of weeks ago: I
>> wrote a program that was running happily on Sarge, then somebody wanted
>> to build it on RHEL and failed beca
On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
>
> > And guess what? System tests are actually more reliable, especially
> > when the user tells you what the system is. You can simply flip to
> > compiling foo_
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
> And guess what? System tests are actually more reliable, especially
> when the user tells you what the system is. You can simply flip to
> compiling foo_linux.c or foo_solaris.c and go on your way.
This will never work. Real life
Steve Greenland <[EMAIL PROTECTED]> writes:
> And guess what? System tests are actually more reliable, especially
> when the user tells you what the system is. You can simply flip to
> compiling foo_linux.c or foo_solaris.c and go on your way.
If you only port to 2 or 3 different very well-defined
On 14-Aug-06, 23:35 (CDT), Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> Steve Greenland wrote:
> Um, this is the exact opposite of the philosophy promoted by Autoconf since
> at least version 2.0. "Feature tests, not system tests". I can't speak to
> other autotools.
Doesn't matter ("feature t
* Steve Greenland <[EMAIL PROTECTED]> [060814 23:30]:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase.
On Mon, Aug 14, 2006 at 09:40:41PM -0400, Michael Poole wrote:
> Wouter Verhelst writes:
>
> >> In my experience, this is greatly exacerbated and perhaps even
> >> primarily due to older versions of autotools encouraging or requiring
> >> behavior that later versions of autotools declare to be bro
[Michael Poole]
> On top of the default automake behavior being horribly broken, does
> that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should never recompile configure.ac or Makefile.am except under
controlled cond
Adam Borowski <[EMAIL PROTECTED]> writes:
> Autotools do require you to do things the way they want, indeed. And
> every single autotool uses a different obscure language. Some
> consistency would be good -- but, I challenge you: write something
> that works better. There's a lot of deficiencies
Steve Greenland wrote:
> On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote:
>> Wouter Verhelst writes:
>> > In the case of autotools, the fact is that usually it's configure.ac or
>> > Makefile.am being horribly broken, rather than the autotools.
Oh yeah. Most people don't know
Wouter Verhelst writes:
>> In my experience, this is greatly exacerbated and perhaps even
>> primarily due to older versions of autotools encouraging or requiring
>> behavior that later versions of autotools declare to be broken.
> [...]
>> The situation is not helped when these mutually incompati
On Mon, Aug 14, 2006 at 03:53:40PM -0700, Russ Allbery wrote:
> Steve Greenland <[EMAIL PROTECTED]> writes:
> > The *real* problem with the whole autotools disaster is that it promotes
> > a braindead idea of how to achieve portability: a #ifdef branch for
> > every different system (or library ve
Steve Greenland <[EMAIL PROTECTED]> writes:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase. Real por
On Mon, Aug 14, 2006 at 04:59:24PM -0400, Michael Poole wrote:
> Wouter Verhelst writes:
>
> > On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> >> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> >> > At 1155391794 past the epoch, Bernd Schubert wrote:
> >> >
Am Montag 14 August 2006 23:10 schrieb Bernd Schubert:
> Wouter Verhelst wrote:
> > If used properly, autotools usually do their job; and pretty well, too.
>
> Just have a look here http://lwn.net/Articles/188693
KDE never used the autotools properly (I'd rather call it hacking into it),
probably
Steve Greenland <[EMAIL PROTECTED]> writes:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase. Real por
Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
>> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> > At 1155391794 past the epoch, Bernd Schubert wrote:
>> > > Btw, why always the autotools while there's this nice
>> > > cmake?
>> >
>
On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote:
> Wouter Verhelst writes:
> > In the case of autotools, the fact is that usually it's configure.ac or
> > Makefile.am being horribly broken, rather than the autotools.
>
> In my experience, this is greatly exacerbated and perhaps
On Mon, Aug 14, 2006 at 09:52:01PM +0200, Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> > On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> > > At 1155391794 past the epoch, Bernd Schubert wrote:
> > > > Btw, why always the autotools
Wouter Verhelst writes:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
>> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> > At 1155391794 past the epoch, Bernd Schubert wrote:
>> > > Btw, why always the autotools while there's this nice
>> > > cmake?
>> >
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> > At 1155391794 past the epoch, Bernd Schubert wrote:
> > > Btw, why always the autotools while there's this nice
> > > cmake?
> >
> > I've never used cmake myse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Greenland wrote:
> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> At 1155391794 past the epoch, Bernd Schubert wrote:
>>> Btw, why always the autotools while there's this nice
>>> cmake?
>> I've never used cmake myself, so
On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> At 1155391794 past the epoch, Bernd Schubert wrote:
> > Btw, why always the autotools while there's this nice
> > cmake?
>
> I've never used cmake myself, so I can't speak for how nice
> it is, but autotools (for all its problem
Alle Saturday 12 August 2006 16:09, Jon Dowland ha scritto:
> At 1155391794 past the epoch, Bernd Schubert wrote:
> > Btw, why always the autotools while there's this nice
> > cmake?
>
> I've never used cmake myself, so I can't speak for how nice
> it is, but autotools (for all its problems) is ver
At 1155391794 past the epoch, Bernd Schubert wrote:
> Btw, why always the autotools while there's this nice
> cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
widespread.
> The cmake build system might even get accepted by Joe
> The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a
> 100% free fork of cdrtools.
> The SVN is inactive from 6 month, but the autotool-ization is already
> done and it can write on DVDs, and probably is better than starting
> another fork.
Btw, why always the autotools while
Joerg Jaspert <[EMAIL PROTECTED]> writes:
> reassign 377109 ftp.debian.org
> retitle 377109 RM: cdrtools -- RoM: non-free, license problems
> thanks
>
> Hi guys,
>
> ok well, as JS stays with an interpretation of CDDL and GPL that the
> whole world does not follow (all wrong, of course :) ), lets
Alle Friday 11 August 2006 22:51, Joerg Jaspert ha scritto:
> reassign 377109 ftp.debian.org
> retitle 377109 RM: cdrtools -- RoM: non-free, license problems
> thanks
>
> Hi guys,
>
> ok well, as JS stays with an interpretation of CDDL and GPL that the
> whole world does not follow (all wrong, of c
Claudio Moratti <[EMAIL PROTECTED]> wrote:
> Hi *
>
> I sent, some time ago, two ITPs: vamps (#320067) and k9copy (#320045)...
>
> Packages are ready, but vamps can not enter in Debian, because the upstream
> author don't want to make public his real identity (now in debian/copyright
> I've a "V
Scripsit Benjamin Seidenberg <[EMAIL PROTECTED]>
> Suggestion: Why don't all the readers of debian-devel put something
> like this on their blogs:
Good idea (but probably not Debian-specific blogs). One should not
probably not copy this exact text; I imagine Google will think higher
of the links
Ken Bloom wrote:
Henning Makholm wrote:
Scripsit Chris Boyle <[EMAIL PROTECTED]>
On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote:
I though a robots.txt thingy on the list web archive is coming to the
rescue ?
Huh? Isn't having the lists searchable gen
Henning Makholm wrote:
> Scripsit Chris Boyle <[EMAIL PROTECTED]>
>
>>On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote:
>
>
>>>I though a robots.txt thingy on the list web archive is coming to the
>>>rescue ?
>
>
>>Huh? Isn't having the lists searchable generally a good thing?
>
>
> Yes
Scripsit Chris Boyle <[EMAIL PROTECTED]>
> On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote:
>> I though a robots.txt thingy on the list web archive is coming to the
>> rescue ?
> Huh? Isn't having the lists searchable generally a good thing?
Yes, a very good thing in general. But excluding
On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote:
> I though a robots.txt thingy on the list web archive is coming to the
> rescue ?
Huh? Isn't having the lists searchable generally a good thing? Or has it
been decided that it causes more harm than it's worth with cases like
this one?
--
Ch
On Thu, Nov 24, 2005 at 12:31:51PM +0100, Simon Richter wrote:
> Hello,
>
> Frank Maffia wrote:
>
> >I have also asked to be removed from 'Call Wave'. I am also on Comcast
> >broadband but my Visa card is still being billed.
>
> You have reached the Debian project. As such, we are not affiliate
Hello,
Frank Maffia wrote:
I have also asked to be removed from 'Call Wave'. I am also on Comcast
broadband but my Visa card is still being billed.
You have reached the Debian project. As such, we are not affiliated in
any way with them, however Google shows our pages as especially relevant
[EMAIL PROTECTED] (Bob Proulx) writes:
> Should I send you a photocopy of the original cdroms that I used to
> install on my system?
Actually, that can be useful, if only to verify just what version was
installed :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
The Fungi writes:
> Perhaps I'm missing something, but it seems to me that it would be more
> effective to try to get http://www.callwave.com/members/cancel/ bumped up
> to the top of the google search instead.
Now that sounds sensible.
--
John Hasler
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
David Pashley writes:
> I'd hope that people actually clicked on the page in question rather
> than just seeing the email address in the summary on the google search.
We don't hear from those ones.
> But yes, I agree that some users are occasionally stupid or lazy or both.
Those we do hear from.
David Pashley wrote:
> John Hasler praised the llamas by saying:
> > And helping people get off C4LL W4VE is not our job.
>
> Surely we should do our best to help all computer users, not just Debian
> users. :)
It is not practical nor even possible to do so. The noise is
overwhelming!
I have a p
On Tue, Sep 06, 2005 at 04:44:41PM +0100, David Pashley wrote:
[...]
> Even still, it's worth trying to get
> http://lists.debian.org/debian-devel/2005/01/msg01444.html bumped
> up to the top of the google search all the same.
[...]
Perhaps I'm missing something, but it seems to me that it would b
On Sep 05, 2005 at 18:33, John Hasler praised the llamas by saying:
> David Pashley writes:
> > No, because that doesn't help the next person that searches on Google.
>
> If these people read the messages they find with their searches they
> wouldn't post here. They don't. They just grab the add
Just fix the program that generates our HTML mailing list archives, and
make it output for mails which
contain any of the Forbidden Words!
Richard
--
__ _
|_) /| Richard Atterer | GnuPG key:
| \/¯| http://atterer.net | 0x888354F7
¯ '` ¯
--
To UNSUBSCRIBE, email to [EMA
Benjamin Seidenberg wrote:
> I wonder if it would be possible to appeal to google to have them
> manually edit that search so that l.d.o doesn't appear. (Same for
> [replaced with "string instrument" to avoid another google hit]'s)
What I think I would rather see is targeted moderation of anything
David Pashley writes:
> No, because that doesn't help the next person that searches on Google.
If these people read the messages they find with their searches they
wouldn't post here. They don't. They just grab the address and spam us.
And helping people get off C4LL W4VE is not our job.
> I b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Proulx wrote:
> David Pashley wrote:
>
>>> Don't follow up. Reply to them privately.
>>
>> No, because that doesn't help the next person that searches on
>> Google.
>
>
> That is exactly the point. We DO NOT WANT people to find the
> Debian mailin
On Sep 05, 2005 at 18:14, Bob Proulx praised the llamas by saying:
> David Pashley wrote:
> > > Don't follow up. Reply to them privately.
> >
> > No, because that doesn't help the next person that searches on Google.
>
> That is exactly the point. We DO NOT WANT people to find the Debian
> mail
David Pashley wrote:
> > Don't follow up. Reply to them privately.
>
> No, because that doesn't help the next person that searches on Google.
That is exactly the point. We DO NOT WANT people to find the Debian
mailing lists in any relation to that search. Every time someone
references it in a
On Sep 05, 2005 at 17:13, John Hasler praised the llamas by saying:
> David Pashley writes:
> > I believe it is far more useful to follow up to these emails providing
> > useful information how to remove themselves and in particular link to the
> > rather informative email from Josh Metzler[0] so t
David Pashley writes:
> I believe it is far more useful to follow up to these emails providing
> useful information how to remove themselves and in particular link to the
> rather informative email from Josh Metzler[0] so that they might find out
> how to do it themselves rather than emailing the l
On Sep 05, 2005 at 16:31, John Hasler praised the llamas by saying:
> Please do not follow up to these messages. These idiots apparently Google
> the phrase and then spam all the addresses they find. Posting about the
> subject here just creates more hits.
I believe it is far more useful to foll
1 - 100 of 132 matches
Mail list logo
