Re: remove

[Petri Latvala]

On Wed, Feb 23, 2005 at 11:33:08PM -0600, Michael Lande wrote:
> Remove me from the list or explain how!
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact 
> [EMAIL PROTECTED]
 

Read all of the messages. The relevant info is right there.


-- 
Petri Latvala


signature.asc
Description: Digital signature

Re: remove

[Glenn Maynard]

On Thu, Feb 24, 2005 at 07:54:37AM +0200, Petri Latvala wrote:
> On Wed, Feb 23, 2005 at 11:33:08PM -0600, Michael Lande wrote:
> > Remove me from the list or explain how!
> > 
> > -- 
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact 
> > [EMAIL PROTECTED]
>  
> 
> Read all of the messages. The relevant info is right there.

Do it!  NOW!

Er.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[Simon Richter]

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 
when it comes to removing people from the Call Wave service, mainly 
because the address you sent this mail to is a public mailing list which 
is archived.


Most likely, your results page already contained the URL 
http://lists.debian.org/debian-devel/2005/01/msg01444.html , which 
should answer your question (the reasons why I don't repeat the answer 
here lie in Google's internal workings; as we cannot remove the result 
from Google easily, we attempt to at least get the page containing the 
instructions towards the top of the list so it can be found more easily)


I hope this helps,

   Simon


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[paddy]

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 affiliated in 
> any way with them, however Google shows our pages as especially relevant 
> when it comes to removing people from the Call Wave service, mainly 
> because the address you sent this mail to is a public mailing list which 
> is archived.
> 
> Most likely, your results page already contained the URL 
> http://lists.debian.org/debian-devel/2005/01/msg01444.html , which 
> should answer your question (the reasons why I don't repeat the answer 
> here lie in Google's internal workings; as we cannot remove the result 
> from Google easily, we attempt to at least get the page containing the 
> instructions towards the top of the list so it can be found more easily)

I though a robots.txt thingy on the list web archive is coming to the rescue ?

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[Chris Boyle]

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?

-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[Henning Makholm]

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 specifically the
posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of
course, that is if somebody can be bothered to keep such exclusion
lists up-to-date.

On the other hand, l.d.o. is not the only place debian-devel is
publicly archived, so it might not be worth the trouble to try to
fix things locally.

-- 
Henning Makholm  "What has it got in its pocketses?"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[Ken Bloom]

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, a very good thing in general. But excluding specifically the
> posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of
> course, that is if somebody can be bothered to keep such exclusion
> lists up-to-date.
> 
> On the other hand, l.d.o. is not the only place debian-devel is
> publicly archived, so it might not be worth the trouble to try to
> fix things locally.

It's not. When querying for "Call Wave remove", the top hits are on a
message from opensubscriber.com. When googling for "callwave remove" we
get a page on lists.debian.org:
http://lists.debian.org/debian-devel/2005/01/msg01444.html

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove

[Benjamin Seidenberg]

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 generally a good thing?
 


Yes, a very good thing in general. But excluding specifically the
posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of
course, that is if somebody can be bothered to keep such exclusion
lists up-to-date.

On the other hand, l.d.o. is not the only place debian-devel is
publicly archived, so it might not be worth the trouble to try to
fix things locally.
   



It's not. When querying for "Call Wave remove", the top hits are on a
message from opensubscriber.com. When googling for "callwave remove" we
get a page on lists.debian.org:


--Ken Bloom

 

And now you're perpetuating the trend, since you have that link next to 
the keyword.
Suggestion: Why don't all the readers of debian-devel put something like 
this on their blogs:


Google has a tendency for improperly indexed items to stay that way. In 
order to fix this, it is neccessary to create a "google bomb" by having 
several sites all create a link to the correct page with the keyword. In 
order to fix an incorrect entry that causes spam to the debian-devel 
mailinglist, I want everyone to know that you should go here to _remove 
callwave_ [0].


Cheers,
Benjamin

[0] http://www.callwave.com/members/help/help.asp?item=SEARCH_cancel


signature.asc
Description: OpenPGP digital signature

Re: Remove

[Henning Makholm]

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 they have _different_ contexts.

Now we're at it, also add the link

  http://wwws.sheetmusicplus.com/sheetmusic/detail/WB.GS2001.html

for "du*l*ng b*nj*s" (remember to spell du*l*ng with a single l, which
is the spelling that has been misdirected to d-l).

-- 
Henning Makholm   "The Board views the endemic use of PowerPoint
   briefing slides instead of technical papers as an
 illustration of the problematic methods of technical communicaion at NASA."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove libflash

[William Pitcock]

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.
> And, this has a lot of problems. 
>  
> Only this package supported the reproduction of Flash by a browser before. 
> However, there is grate free software such as swfdec[1] and gnash[2] and 
> other, 
> and new Flash is supported now. 
> 
> Then, I think to delete this package from Debian. 
> I get an opinion from other developers[3], but think that I want the opinion 
> from 
> the user/developper that is interested in this package. 
> 
> I think that I will give the deletion request of this package from Debian 
> if there is not an opinion. 
> 
> Best regards,
>  Nobuhiro
> 
> [0]:http://packages.qa.debian.org/libf/libflash.html
> [1]:http://packages.debian.org/source/sid/swfdec0.6
> [2]:http://packages.qa.debian.org/g/gnash.html
> [3]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+495040
> - -- 
> Nobuhiro Iwamatsu
>   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]
> 
>   GPG ID : 3170EBE9
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAkiwDQYACgkQQSHHQzFw6+meuQCgqaBvF3trdqlnXXtSv7V6Z74a
> UnUAoJnkn3ryYe2LjSoho1ABrIDsL4xj
> =GScE
> -END PGP SIGNATURE-
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: remove ruby1.6

[Nico Golde]

Hi,
* akira yamada / [EMAIL PROTECTED]"$-$i <[EMAIL PROTECTED]> [2005-08-12 11:49]:
> I think that ruby1.6 should be removed from Debian.
> Because Ruby 1.6.x is the old stable version of Ruby.
> (current stable version is Ruby 1.8.x.)
> 
> In unstable, the following packages depend on ruby1.6:

I also think this would be a good idea.
Do you have an idea how many of them are packaged with
1.8 too?
regards nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove ruby1.6

[akira yamada / やまだあきら]

Nico Golde wrote:
> Do you have an idea how many of them are packaged with
> 1.8 too?

The following source packages generate binary packages
for ruby1.6 only:

  aswiki
  drb (*)
  erb (*)
  gnome-ruby
  libhonyaku-damashii-ruby
  libiconv-ruby (*)
  libmutexm-ruby (*)
  libnet-acl-ruby (*)
  libopenssl-ruby (*)
  liboptparse-ruby (*)
  libstrscan-ruby (*)
  libyaml-ruby (*)
  libzlib-ruby (*)
  racc (*)
  riece
  rsjog
  ruby-eserver (*)
  soap4r (*)
  tdiary
  testunit (*)
  tictactoe
  webrick (*)
  xmlrpc4r (*)

Packages marked with "*" is merged into ruby1.8.

Gnome-ruby provides binary packages for ruby1.6 only.
But gnome2-ruby provides binary packages for ruby1.8.
(And gnome-ruby is obsoleted by upstream author.)

Riece (riece-google and riece-rdcc) depends on
ruby1.6 or ruby1.8.

libhonyaku-damashii-ruby is a library to connect to
very old proprietary application.  I think that
there is few users of this package.
(http://popcon.debian.org/contrib/interpreters/by_inst>)

I don't know about aswiki, rsjog, tdiary (tdiary-plugin)
and tictactoe.  (I use tDiary on ruby1.8 and I have no problem.)


Thank you.
-- 
akira yamada


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove ruby1.6

[Steve Langasek]

Hi Akira,

On Fri, Aug 12, 2005 at 10:24:05PM +0900, akira yamada / やまだあきら wrote:
> Nico Golde wrote:
> > Do you have an idea how many of them are packaged with
> > 1.8 too?

> The following source packages generate binary packages
> for ruby1.6 only:

Thanks for this list.  It appears that the following packages can be removed
from testing/unstable with no ill effects, since they have no
reverse-dependencies outside of this set:

>   drb (*)
>   erb (*)
>   libmutexm-ruby (*)
>   libnet-acl-ruby (*)
>   libopenssl-ruby (*)
>   liboptparse-ruby (*)
>   ruby-eserver (*)
>   soap4r (*)
>   xmlrpc4r (*)
>   testunit (*)
>   webrick (*)

Is there any reason not to file for immediate removal of these packages?  If
not, could the maintainers please do this?


The next packages have other reverse-dependencies which prevent their
removal from testing; some of them are the applications that are listed at
the bottom, included in your original list of ruby1.6-only packages:

>   gnome-ruby

Used by tictactoe, rsjog, and mhc-utils; should be ported to gnome2-ruby, I
guess?

>   libiconv-ruby (*)

Needed by dnsdoctor and zonecheck, which presumably also need porting to
ruby1.8.

>   racc (*)

Needs rdtool and libtmail-ruby updated to be ruby1.8-only before it can be
removed from testing, but could be removed from unstable at any time.

>   libstrscan-ruby (*)

Used by aswiki.  The packages amrita and rdtool would also need to drop
their ruby1.6 support before this package could be removed from testing.

>   libyaml-ruby (*)

Needed by dnsdoctor, zonecheck, and sisu.

>   libzlib-ruby (*)

The libzip-ruby package needs to drop its ruby1.6 support before this
package could be removed from testing.  In addition, debpartial depends on
libzlib-ruby (>= 0.5.1-1); this package probably needs to be rebuilt to drop
this dependency?


Finally, there are the application packages, which would need to be ported
to ruby1.8 (or at least, updated to use ruby1.8 instead of ruby1.6):

>   aswiki
>   riece
>   rsjog
>   tdiary
>   tictactoe

> Riece (riece-google and riece-rdcc) depends on
> ruby1.6 or ruby1.8.

> I don't know about aswiki, rsjog, tdiary (tdiary-plugin)
> and tictactoe.  (I use tDiary on ruby1.8 and I have no problem.)

Have the maintainers of these packages been contacted directly about
switching to ruby1.8?
   
Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: remove ruby1.6

[Michael Ablassmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

On Sun, Aug 14, 2005 at 05:35:35AM -0700, Steve Langasek wrote:
> > I don't know about aswiki, rsjog, tdiary (tdiary-plugin)
> > and tictactoe.  (I use tDiary on ruby1.8 and I have no problem.)

tictactoe (0.8.1-2) has been uploaded yesterday and now uses
ruby1.8/libgtk2-ruby.

bye,
- michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC/z9dEFV7g4B8rCURAsz0AJ0aPFix82B7lhdtJ6uzAIxsPFFaZwCfYPsv
3Dz/1NqFDmuKGZgu+CDvXhI=
=6X/Y
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove ruby1.6

[Jon Dowland]

On Fri, Aug 12, 2005 at 06:29:58PM +0900,  wrote:
> Hi,
> 
> I think that ruby1.6 should be removed from Debian.
> Because Ruby 1.6.x is the old stable version of Ruby.
> (current stable version is Ruby 1.8.x.)

I had authored some very simple ruby scripts on a stable machine in 1.6
which are now totally broken in 1.8. I think updating code from 1.6 to
1.8 is a very non-trivial task, it appears a lot has changed.

-- 
Jon Dowland   http://jon.dowland.name/
FD35 0B0A C6DD 5D91 DB7A  83D1 168B 4E71 7032 F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove ruby1.6

[Dmitry Borodaenko]

On Sun, Aug 14, 2005 at 05:35:35AM -0700, Steve Langasek wrote:
> >   libyaml-ruby (*)
> Needed by dnsdoctor, zonecheck, and sisu.

libyaml-ruby binary package is a dependency package built from
ruby-defaults source package and depends on libyaml-ruby1.8 (default
Ruby version); libyaml-ruby1.6 binary package is built from libyaml-ruby
source package.

All three packages mentioned above have versioned depends on ruby >=
1.8.x and non-versioned depends on libyaml-ruby, apparently, they don't
need libyaml-ruby1.6.

I'm requesting removal of libyaml-ruby from unstable.

-- 
Dmitry Borodaenko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Gabor Gombas]

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 doesn't.

If you want more information you can always do "bash -xv ./configure
..."

> Hmmm, why is it checking for "string.h" and "limits.h" after it has
> already checked for "ANSI C header files"?

Because whoever created configure.ac told it to do so?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove me

[Michelle Konzack]

rm -rf [EMAIL PROTECTED] >/dev/null

done.

Am 2005-01-10 13:49:57, schrieb [EMAIL PROTECTED]:
> remove me from call wave. thank you
- ENE OF REPLYED MESSAGE -

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: remove me

[Christian Perrier]

Quoting Michelle Konzack ([EMAIL PROTECTED]):
> rm -rf [EMAIL PROTECTED] >/dev/null


Nope, you're definitely wrong. The correct command line should be:

cd "call wave"  ; rm -f [EMAIL PROTECTED] >/dev/null

The user explicitely asked for being removed from call wave only.:)

I'm pretty sure other fellow DD's will find nice ways to enhance this
and correct my poor shell syntax, though.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove me

[Chasecreek Systemhouse]

On Mon, 10 Jan 2005 23:07:06 +0100, Christian Perrier
<[EMAIL PROTECTED]> wrote:
> Quoting Michelle Konzack ([EMAIL PROTECTED]):
> > rm -rf [EMAIL PROTECTED] >/dev/null

> Nope, you're definitely wrong. The correct command line should be:
> 
> cd "call wave"  ; rm -f [EMAIL PROTECTED] >/dev/null
> 
> The user explicitely asked for being removed from call wave only.:)
> 
> I'm pretty sure other fellow DD's will find nice ways to enhance this
> and correct my poor shell syntax, though.

=)

Removal from all instances would be required:

updatedb
locate "call wave" | grep "[EMAIL PROTECTED]" >> possible_call_wave_locations
perl -w removal.pl possible_call_wave_locations

= cut source ===

use strict;
use diagnostics;

# must be root...
die "You are not root ... good-bye..." if $<;

# Pass me a file to parse - unless I am NOT root...
my $remove = @ARGV ? $ARGV[0] : 'unknown';

# Exit on error...
die "nothing to parse ..." if ($remove =~ /unknown/i);

# You *could* sort the data ... something like
# my $sorted = `cut -f3 -d: $gf > $us && sort -n $us`;

my $erc= '';
my $test   = '';
my $targets = 0;

foreach $test ( (split(/\n/, $removal)) ) {

$erc = system("rm -fR $test") / 256 unless $<;
print "\n\nError Cannot remove you from Call Wave $! $erc" if $erc;

}

__END__

*** modified from:
http://backpan.cpan.org/authors/id/S/SN/SNEEX/addgroup.sx


This is all totally in good fun and completely untested...

Cheers!
-- 
WC -Sx- Jones
http://insecurity.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Francesco Pedrini]

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 course :) ), lets go and
> fix this. The sane way is to remove cdrtools from Debian main
> (unstable) and add a free replacement, most possible a fork from the
> last free version (which had only the CDDL licensed build scripts,
> which can easily be replaced by some automake thing). If you want to
> join that effort - contact me.

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.

One interesting thing on this project is that they want to turn 
important functionality into a shared library for improve the access 
from the various frontends.

Regards,
Francesco
-- 
:wq


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Goswin von Brederlow]

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 go and fix
> this. The sane way is to remove cdrtools from Debian main (unstable) and
> add a free replacement, most possible a fork from the last free version
> (which had only the CDDL licensed build scripts, which can easily be
> replaced by some automake thing). If you want to join that effort -
> contact me.
>
> For Debian etch I dont think its a big problem right now, dependencies
> will stop it from getting removed before we release.

For those that didn't see it on irc there is also a replacement for
cdrecord called cdrskin based on the JS free libburn. The BIG problem
with it is that it can only burn data CDs in disk-at-once mode. No TAO
or audio capabilities.

For anyone intrested Eduart Block and some others have packaged it in
the last 24h: svn.debian.org/svn/collab-maint/deb-maint/cdrskin/trunk

I know it is far from being a full replacement but good enough to
e.g. burn Debian CDs.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Bernd Schubert]

> 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 there's this nice cmake? The cmake build
system might even get accepted by Joerg, as it can create makefiles for MS
compilers (I know, its not important to this list and also not to me, but
it seems to be important for Joerg).

Cheers,
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Jon Dowland]

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 Joerg,
> as it can create makefiles for MS compilers (I know, its
> not important to this list and also not to me, but it
> seems to be important for Joerg).

I'd consider that points /against/ it's favour.

-- 
Jon Dowland
http://alcopop.org/


signature.asc
Description: Digital signature

Re: Remove cdrtools

[Francesco Pedrini]

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 very
> widespread.

the same for me.

> > The cmake build system might even get accepted by Joerg,
> > as it can create makefiles for MS compilers (I know, its
> > not important to this list and also not to me, but it
> > seems to be important for Joerg).
>
> I'd consider that points /against/ it's favour.

If a new free fork is started JS has nothing to do with it, IMHO.

-- 
:wq


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 problems) is very
> widespread.

So is syphilis. That doesn't make it desirable.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Ron Johnson]

-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 I can't speak for how nice
>> it is, but autotools (for all its problems) is very
>> widespread.
> 
> So is syphilis. That doesn't make it desirable.

But it *does* make it hard to eradicate...


- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE4N5DS9HxQb37XmcRAmbcAKDM4aX9qZu7wfnp8Rz/2VDgZWctEACgqhAF
Md5XpR8Q4O69/17JqtGDfL4=
=jdrl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Wouter Verhelst]

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 myself, so I can't speak for how nice
> > it is, but autotools (for all its problems) is very
> > widespread.
> 
> So is syphilis. That doesn't make it desirable.

Syphilis is a disease. Software usually isn't.

In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.

If used properly, autotools usually do their job; and pretty well, too.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Michael Poole]

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? 
>> > 
>> > 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.
>> 
>> So is syphilis. That doesn't make it desirable.
>
> Syphilis is a disease. Software usually isn't.
>
> 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 even
primarily due to older versions of autotools encouraging or requiring
behavior that later versions of autotools declare to be broken.

automake is the persistent offender here -- conditionally compiled
source files is a good example, where automake-1.5's info pages said
to do it one way, 1.6 said to do it another way (and complained if you
did it the 1.5 way), and IIRC 1.7+ prefer yet another way and broke
the 1.5 way of doing things.

autoconf has had some similar cases, such as the help string for
AC_ARG_WITH -- which is used by a large majority of autotooled
programs -- being one way for <2.59 but wanting AS_HELP_STRING in
2.59.  Unfortunately, the old way produces goofy formatting (and maybe
a warning; I forget exactly) under 2.59.

The situation is not helped when these mutually incompatible programs
all prefer to be called "automake" or "autoconf" and, on less helpful
distributions, do not install themselves as automake-1.9 (etc).

Michael Poole


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Adam Borowski]

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 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.
> > 
> > So is syphilis. That doesn't make it desirable.
> 
> Syphilis is a disease. Software usually isn't.

For those who disparage automake:
* apt-get source tcng
* say a prayer; using multiple pantheons is a good idea
* take a look at its Makefiles
* have a drink or ten
* for x in `find -iname Makefile`;do dd if=/dev/random ...

For those who disparage autoconf, a look at Schily makesystem will
have a similar effect.

THESE are syphilis or worse.
 
> In the case of autotools, the fact is that usually it's configure.ac or
> Makefile.am being horribly broken, rather than the autotools.

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 in autotools, but
everything so far is A LOT worse.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 even
> primarily due to older versions of autotools encouraging or requiring
> behavior that later versions of autotools declare to be broken.

That's *one* of the problems. If you only ever compile on Linux or *BSD,
it might seem the most common.

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 portability involves understanding
your target systems, learning where the rough edges and corner cases
are, and developing proper abstractions to work around them. Oh, and
actually learning the standard version of the language (if there is
one), and being able to distinguish between "this is what the language
says it will do" and "works for me".

The sad thing is that Henry Spencer warned us 15 years ago[1], and
nobody learned a damn thing.

Steve

[1] http://www.literateprogramming.com/ifdefs.pdf

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Bernd Schubert]

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?
>> > 
>> > 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.
>> 
>> So is syphilis. That doesn't make it desirable.
> 
> Syphilis is a disease. Software usually isn't.
> 
> In the case of autotools, the fact is that usually it's configure.ac or
> Makefile.am being horribly broken, rather than the autotools.
> 
> If used properly, autotools usually do their job; and pretty well, too.
> 

Just have a look here http://lwn.net/Articles/188693


Cheers,
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Russ Allbery]

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 portability involves understanding
> your target systems, learning where the rough edges and corner cases
> are, and developing proper abstractions to work around them. Oh, and
> actually learning the standard version of the language (if there is
> one), and being able to distinguish between "this is what the language
> says it will do" and "works for me".

I'm not sure you can really blame autotools for this.  In a well-designed
application with a good portability abstraction layer, the autotools are
as good as any for providing the input required to create that portability
layer.

In other words, my preferred coding practice is to use autotools to probe
the system capabilities and selectively enable a portability layer that
deals with missing functionality required for that system.  Then, isolate
all #ifdefs and the like in that portability layer and code the rest of
the application against standard POSIX and ISO C99 functionality, using
the portability layer where necessary.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Hendrik Sattler]

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 because moc is designed to be used with qmake.

HS


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Wouter Verhelst]

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:
> >> > > 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.
> >> 
> >> So is syphilis. That doesn't make it desirable.
> >
> > Syphilis is a disease. Software usually isn't.
> >
> > 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 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 incompatible programs
> all prefer to be called "automake" or "autoconf" and, on less helpful
> distributions, do not install themselves as automake-1.9 (etc).

Why should that matter at all?

Autotools are tools for the upstream developer, and have had features to
declare what version the configure.ac or Makefile.am files are supposed
to be used with for quite some time now. You distribute a package that
is already autotooled; the person who compiles the software doesn't need
autotools.

In case they do, your way of using autotools is horribly broken.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Ben Pfaff]

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 portability involves understanding
> your target systems, learning where the rough edges and corner cases
> are, and developing proper abstractions to work around them. Oh, and
> actually learning the standard version of the language (if there is
> one), and being able to distinguish between "this is what the language
> says it will do" and "works for me".

Use of gnulib can help with this.  It provides a number of useful
abstractions that can help to avoid #ifdefs in some common
situations:
http://savannah.gnu.org/p/gnulib
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Langasek]

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 version, or whatever), strewn
> > throughout the entire codebase. Real portability involves understanding
> > your target systems, learning where the rough edges and corner cases
> > are, and developing proper abstractions to work around them. Oh, and
> > actually learning the standard version of the language (if there is
> > one), and being able to distinguish between "this is what the language
> > says it will do" and "works for me".

> I'm not sure you can really blame autotools for this.  In a well-designed
> application with a good portability abstraction layer, the autotools are
> as good as any for providing the input required to create that portability
> layer.

Indeed, the only reason to use autoconf in the first place is if you're
trying to *avoid* platform-specific ifdef mazes.  That some authors happen
to do an imperfect job of this isn't something that should be blamed on
autoconf AFAICS.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Michael Poole]

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 incompatible programs
>> all prefer to be called "automake" or "autoconf" and, on less helpful
>> distributions, do not install themselves as automake-1.9 (etc).
>
> Why should that matter at all?
>
> Autotools are tools for the upstream developer, and have had features to
> declare what version the configure.ac or Makefile.am files are supposed
> to be used with for quite some time now. You distribute a package that
> is already autotooled; the person who compiles the software doesn't need
> autotools.
>
> In case they do, your way of using autotools is horribly broken.

This means the default operation of automake is horribly broken.  (See
the lengthy comment in /usr/share/doc/autotools-dev/README.Debian.gz
on AM_MAINTAINER_MODE if its problems slipped your mind.)

The usual way for people to use version control is to keep the source,
and provide scripts as appropriate to derive the program.  Because of
this, it is not common to put aclocal.m4, configure, or the other
generated files into version control.  Thus, anyone who downloads
software from version control must run aclocal, autoheader, automake,
autoconf, possibly libtool, etc.  This is when backwards incompatible
changes cause problems.

On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?

Michael Poole


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Nathanael Nerode]

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 how to write Makefiles, of course, which is
a bigger problem.  Automake doesn't know how to write them either.  Google
"Make is an expert system".  There should be as little as possible in the
procedural code: if you can express something with dependencies, you
should do it.

Unfortunately Make is missing one crucial feature which would allow most
Makefiles to be much, much cleaner.  I have been meaning to write a patched
version of make which includes it, but I never seem to get around to it. 
It's very simple: for each target, it should be possible to specify a piece
of procedural code which returns 0 if the target is considered 'up-to-date'
and 1 if it is not considered 'up-to-date'.  Think about the potential uses
of that for a minute.  :-)

> 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.

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.

> Real portability involves understanding  
> your target systems, learning where the rough edges and corner cases
> are, and developing proper abstractions to work around them.

Furthermore, 'best practice' use of autoconf is to isolate the feature
differences in a single piece of wrapper code, so that your main code only
has to deal with (e.g.) 'memmove', and it's emulated where it isn't
present.  The emulation code is the only code containing #ifdefs, which are
then based on the features detected by autoconf.

I don't think I'd like to work without autoconf.  The alternatives I've seen
are all hideous monstrosities.  Automake -- well, if you know how to write
a Makefile, don't use it, just write your Makefile -- but most people
don't.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Miles Bader]

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 in autotools, but
> everything so far is A LOT worse.

Yup.

The autotools also have the rather nice attribute that if there's any
pain involve, it's only on the part of the developer / distributor --
for the end user who just wants to compile and install the package,
usually everything works quite smoothly, without the necessity of
installing new obscure tools.

The implementation pecularities of autoconf / automake can indeed be
quite annoying at times, but the basic idea behind them is solid, and
ends up working pretty well if you use them the "right way".

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Wouter Verhelst]

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 broken.
> > [...]
> >> The situation is not helped when these mutually incompatible programs
> >> all prefer to be called "automake" or "autoconf" and, on less helpful
> >> distributions, do not install themselves as automake-1.9 (etc).
> >
> > Why should that matter at all?
> >
> > Autotools are tools for the upstream developer, and have had features to
> > declare what version the configure.ac or Makefile.am files are supposed
> > to be used with for quite some time now. You distribute a package that
> > is already autotooled; the person who compiles the software doesn't need
> > autotools.
> >
> > In case they do, your way of using autotools is horribly broken.
> 
> This means the default operation of automake is horribly broken.

No argument there. I once received a mail from someone who claimed he
had argued for doing it this way, and that he regretted that he'd done
so.

Don't ask me who it was, however; I don't recall.

> (See the lengthy comment in
> /usr/share/doc/autotools-dev/README.Debian.gz on AM_MAINTAINER_MODE if
> its problems slipped your mind.)

I would never forget about that issue ;-)

> The usual way for people to use version control is to keep the source,
> and provide scripts as appropriate to derive the program.  Because of
> this, it is not common to put aclocal.m4, configure, or the other
> generated files into version control.  Thus, anyone who downloads
> software from version control must run aclocal, autoheader, automake,
> autoconf, possibly libtool, etc.  This is when backwards incompatible
> changes cause problems.

If you work with VCS-snapshots, then I don't think it's still fair to
consider yourself anything less than "a developer". There will be some
rough edges in that case -- not just because of the autotools usage.

Proper use of AC_PREREQ and friends will ameliorate this problem,
however.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 tests" was what I was trying to express (badly)
with "or library versions or whatever.) Autoconf encourages writing
mainline code with different branches in a maze of #ifdefs.

Okay, maybe *autoconf* doesn't specificly encourage it, but thats how
the vast majority of users of autoconf do it.

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. There are
quite often subtlities in how things work on a particular system that
are not distinguishable by simple compile tests about whether or not
something is there.

> > Real portability involves understanding  
> > your target systems, learning where the rough edges and corner cases
> > are, and developing proper abstractions to work around them.
> 
> Furthermore, 'best practice' use of autoconf is to isolate the feature
> differences in a single piece of wrapper code, so that your main code only
> has to deal with (e.g.) 'memmove', and it's emulated where it isn't
> present.  The emulation code is the only code containing #ifdefs, which are
> then based on the features detected by autoconf.

Ha ha ha ha.

I admit there may be some out there who use it that way. Don't see it
very often.

Also, please, checking for memmove? This is 2006. Everytime I sit
through the endless "checking for memcpy()..." crap I cringe. Why are we
still wasting my time checking for features that were standardized 17
years ago? And don't give me the "but it will still work on old/weird
systems" crap. Most of it won't even compile (much less work!) on
Solaris 2.7 or AIX 5, and those are (relatively) recent C89/Posix
environments.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Miles Bader]

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 system types,
maybe.  But nobody actually has that luxury in the real world.
Coarse-grained "system tests" are a frigging nightmare in the real world.

-Miles
-- 
97% of everything is grunge


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Gabor Gombas]

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 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 because the UUID library on RHEL does not
have uuid_unparse_lower(). And RHEL _is_ Linux and it is pretty heavily
used in corporate environments. So instead of foo_linux.c you need
foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen
more, which is just plainly unmanageable.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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_linux.c or foo_solaris.c and go on your way.
> 
> 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 because the UUID library on RHEL does not
> have uuid_unparse_lower().

So you chose to use a function not reliably available. Sounds like bad
planning to me.

> And RHEL _is_ Linux and it is pretty heavily used in corporate
> environments. So instead of foo_linux.c you need foo_sarge.c,
> foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more,
> which is just plainly unmanageable.

No, you figure out what the base system requirement is, and write to that.

I can guarantee you that there's a lot more difference between AIX and
"Linux" than there is between RHEL 3.x and Debian sarge, not to even
mention non-Unix platforms. None-the-less, code can be written that runs
on all of them. 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.

And yes, you could use autoconf to control those generic functions. But
usually it's overkill. If you actually understand enough about where the
edges of portability are, you don't need autoconf, and if you don't,
autoconf doesn't help, because you waste your time checking for things
that are universally available (memcpy(), string.h) and don't have clue
about variances in signal handling, or why assuming "char" is signed is
a bad idea.

I spend quite a bit of my life working on non-Linux platforms (as well
as a variety of Linux ones). I've built *lots* of free software on these
platforms. 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 damn
near impossible to fix.

Steve

[1] Prior to the widespread adoption of Linux, this was less true;
presumably the developers actually used non-Linux systems.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Matthew Garrett]

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 because the UUID library on RHEL does not
>> have uuid_unparse_lower().
> 
> So you chose to use a function not reliably available. Sounds like bad
> planning to me.

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 flaw. 

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Miles Bader]

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 like a _perfect_ application of ... autoconf!

> I spend quite a bit of my life working on non-Linux platforms (as well
> as a variety of Linux ones). I've built *lots* of free software on these
> platforms. 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 damn
> near impossible to fix.

This is a cultural artifact (of a monoculture made possible by the
relative dominance of linux in its niche), not a result of using
autoconf.

[In the early days of linux, it was much, _much_ worse, because not only
didn't they use autoconf, they didn't even _try_ to be portable, simply
assumed everything was exactly like the exact linux distribution they
happened to be using.]

Programs that work well with "edit the makefile and define SYS to be
sys-FOO.c" style tend to program to the lowest common denominator,
because doing anything else simply becomes too painful with this style
of portability.  This is fine for some apps (and indeed autoconf
supports this sort of thing quite well), but in cases where you _need_
to use more esoteric functionality, it quickly becomes a real pain;
autoconf's emphasis on finer-granularity helps considerably (though it's
always going to be a pain).

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
programmers made a hash of it no matter what style of portability they
choose.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Peter Samuelson]

[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 damn
> near impossible to fix.

This, as you note in your footnote, is probably attributable entirely
to whether the developers actually have a clue that there is more to
Unix than Linux/i386.  The style of uncommenting defines in a Makefile,
versus autoconf, is an _effect_, not a cause - the effect only
_appears_ to be causal because the Unix-ignorant don't tend to use the
former style.  There is, either way, no substitute for awareness of
portability issues, and no substitute for actual development experience
on multiple Unix platforms.

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 of test macros are provided, but nobody forces you to use them.


signature.asc
Description: Digital signature

Re: Remove cdrtools

[Goswin von Brederlow]

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 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 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 because the UUID library on RHEL does not
>> have uuid_unparse_lower().
>
> So you chose to use a function not reliably available. Sounds like bad
> planning to me.
>
>> And RHEL _is_ Linux and it is pretty heavily used in corporate
>> environments. So instead of foo_linux.c you need foo_sarge.c,
>> foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more,
>> which is just plainly unmanageable.
>
> No, you figure out what the base system requirement is, and write to that.
>
> I can guarantee you that there's a lot more difference between AIX and
> "Linux" than there is between RHEL 3.x and Debian sarge, not to even
> mention non-Unix platforms. None-the-less, code can be written that runs
> on all of them. 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.

Then again you have code that depends on the size of variable types,
the availability of header files, libaries, functions in libraries,
different prototypes for functions, .

Instead of finding out what all those parameters are for each system
and writing an foo_.c you can use autoconf to run reliable
testcases for them and use the results to automatically adjust to the
probed set of parameters.

Especialy when you have optional stuff, like 'png support yes/no',
then you need something to easily set the #ifdef variables.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Gabor Gombas]

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
RHEL no matter what. So much for planning.

> I spend quite a bit of my life working on non-Linux platforms (as well
> as a variety of Linux ones). I've built *lots* of free software on these
> platforms. 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 damn
> near impossible to fix.

A couple of years ago I used to be an AIX/Solaris admin and I had quite
the opposite experiences. Installing software that used autoconf was
generally painless, building the software simultaneously on 3 platforms
from a common source (NFS) just worked almost always.

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, they did not
support building outside of the source directory etc.

In case of bugs, autoconf helps a _lot_ since you know that every build
system looks the same, if you find a bug (like libtool being notoriously
broken on AIX) the same bug will be present in every package and the
same fix can be applied etc. On the other hand, all custom build systems
had their own bugs that required a lot more time to investigate.

autoconf/automake/libtool are just like many traditional UNIX tools:
they are all sharp knifes which can cut you deep if you use them badly,
but can also help a lot if you use them wisely.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 flaw. 

You can't have it both ways. Either your program *requires* the
new/unusual functionality exist on the system, in which case it will
never port to the systems that don't have it, or you'll have to
provde a custom implementation, in which case you have the multiple
implementations problem anyway.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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
> programmers made a hash of it no matter what style of portability they
> choose.

My experience is that *most* autoconf using programs are written in the
"bad" style, because (I assume) a *lot* of people think something along
the lines of "my code is portable because I use autoconf". My *opinion*
is a lot of that is a result of the autoconf documentation and examples.

My additional experience is that debugging and fixing autoconf related
problems is a real pain in the ass. 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 and guessing.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Matthew Garrett]

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 fix should there ever be any sort of 
>> security flaw. 
> 
> You can't have it both ways. Either your program *requires* the
> new/unusual functionality exist on the system, in which case it will
> never port to the systems that don't have it, or you'll have to
> provde a custom implementation, in which case you have the multiple
> implementations problem anyway.

Or (c), my program will take advantage of extra functionality when it's 
present. You seem to be asserting that this level of granularity is 
unacceptable, so in your model we end up with a choice between less 
functional software or potential screaming security misery. I think this 
is arbitrary and unnecessary.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 of test macros are provided, but nobody forces you to use them.

But everybody does, to the point where it now often takes (much!) longer
to run configure than to actually build the program. 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. I don't
know if this is something that changed in autoconf, or something that
changed in one of the higher level autotools. I don't particularly care.
It's not whether or not autoconf itself requires this behavriour, it's
that de-facto, *most* autotools using projects exhibit this behaviour.
Probably because the examples or templates use it, and it's easier to
use them unchanged than actually think about what they're doing.

See, my argument is not that autconf *can't* be used in a wise manner;
my argument is that it tends to lead to bad usage, widely propogated.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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 an disaster. There's no point in figuring
out the libtool bug (somewhere in its umpty-thousand lines of sh code)
and submitting a fix, since it will be broken again the next release.

Steve


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Russ Allbery]

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.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[George Danchev]

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 certain range of obsolete baseline tests.  A huge
> > number of test macros are provided, but nobody forces you to use them.
>
> But everybody does, to the point where it now often takes (much!) longer
> to run configure than to actually build the program. 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. I don't
> know if this is something that changed in autoconf, or something that
> changed in one of the higher level autotools. I don't particularly care.
> It's not whether or not autoconf itself requires this behavriour, it's
> that de-facto, *most* autotools using projects exhibit this behaviour.
> Probably because the examples or templates use it, and it's easier to
> use them unchanged than actually think about what they're doing.
>
> See, my argument is not that autconf *can't* be used in a wise manner;
> my argument is that it tends to lead to bad usage, widely propogated.

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 of them have notoriously prolonged life cycle ;-)... it just matters who 
is using them and how.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Matthew R. Dempsky]

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 of them have notoriously prolonged life cycle ;-)... it just matters who 
> is using them and how.

People without the skill to program in error-prone languages are 
encouraged to use more idiot-proof ones instead.  Why isn't the same 
done for build frameworks?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Peter Samuelson]

[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 and guessing.

Too bad autoconf doesn't keep a log of everything configure does.[1]

   [1] In case you missed it, it's called 'config.log'.


signature.asc
Description: Digital signature

Re: Remove cdrtools

[George Danchev]

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 does not make them disused or abandoned (on the
> > contrary some of them have notoriously prolonged life cycle ;-)... it
> > just matters who is using them and how.
>
> People without the skill to program in error-prone languages are
> encouraged to use more idiot-proof ones instead.  

The human itself is prone to error, and even skilled people could make funny 
and hard to detect errs, based on their current mood, attitude and character 
if you want, which tends to be impermanent.

> Why isn't the same done for build frameworks?

/* I rather wrote about their rеsemblance, not their divergence */
Probably because masses first invent and face the error-prone solution, then 
ascertain the fact that they are enough error-prone to be used by mortals, 
which could take quite long periods of time needed to accumulate that 
experience, and then strive to find out and learn about more robust 
approaches. E.g. if Ada predated C, we shouldn't see some of the human-nature 
based errors in UNIX, when you meant foo, but it easily turned to be bar 
instead ;-)... I don't believe this applies to autotools, even though beasts 
like scons seems to be better imho leaving lesser room to dig in errors.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Darren Salt]

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. etc. even for pure C projects.

> This is a libtool bug.

I'm using the following workaround for gxine (due to the browser plugin):

  m4_undefine([AC_PROG_CXX])
  m4_defun([AC_PROG_CXX],[])
  m4_undefine([AC_PROG_F77])
  m4_defun([AC_PROG_F77],[])

before invoking any A[CM]*LIBTOOL*.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

I'd like to, but I have to answer all of my "occupant" letters.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove cdrtools

[Steve Greenland]

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
> > SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
> > return code and guessing.
> 
> Too bad autoconf doesn't keep a log of everything configure does.[1]
> 
>[1] In case you missed it, it's called 'config.log'.

Amazingly enough, I knew about this.

>From an apache2 config.log, just 'cause it's the first one I found:

configure:2533: checking whether gcc accepts -g
configure:2565: checking how to run the C preprocessor
configure:2966: checking for rm
configure:3003: checking for mawk
configure:3044: checking for a BSD compatible install
configure:3097: checking whether ln -s works
configure:3126: checking for ranlib
configure:3192: checking for AIX
configure:3216: checking for POSIXized ISC
configure:3238: checking for minix/config.h
configure:3291: checking for ANSI C header files
configure:3409: checking for string.h
configure:3409: checking for limits.h
configure:3409: checking for unistd.h
configure:3409: checking for sys/socket.h
configure:3409: checking for pwd.h
configure:3409: checking for grp.h

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 doesn't.

Hmmm, why is it checking for "string.h" and "limits.h" after it has
already checked for "ANSI C header files"?

Well, this has devolved into a "Yes it is"/"No it isn't" kind of
argument, and maybe that's all it can be: I don't like the autotools,
because of my particular experiences with them, and others do, because
of their particular experiences.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove a package?

[Jonathan Wiltshire]

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 policies.
> 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, but got no response. Last update of
> official site (http://bcrypt.sourceforge.net/) was in September 2002.
> This program doesn't work and has no support. Is there any reason to
> keep such packages?

Packages can be removed if they aren't in good shape, upstream is dead,
etc. Have you tried pinging bcr...@packages.debian.org? If you got no
response after a reasonable time, the QA team will see if the maintainer
is missing in action (adding them to CC, dropping -devel through BCC).

If you'd like to see bcrypt stay in the archive, you could adopt the
package upstream and also adopt the packaging, or another developer
might be interested. If the current maintainer is MIA, the QA team might
adopt the package themselves. (QA: I'll happily prepare an upload, but
will need sponsorship.)

> 
> Alexey
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 

Best,


-- 
Jonathan Wiltshire

PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52


signature.asc
Description: Digital signature

Re: Remove a package?

[Neil Williams]

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
> Debain policies.

http://www.uk.debian.org/Bugs/Reporting

The pseudo-package you need is:
ftp.debian.org — Problems with the FTP site 

(Although the pseudo-package description doesn't explicitly point at
bugs that cause the removal of a package, checking the actual bug
report page lists lots of RM bugs.)

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org;dist=unstable

There is a particular syntax for such bug reports.

> 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, but got no response. Last update of
> official site (http://bcrypt.sourceforge.net/) was in September 2002.
> This program doesn't work and has no support. Is there any reason to
> keep such packages?

Why remove it when it could be possible to prepare a fixed package,
make it available via mentors.debian.net and get a sponsor to upload it
as an Non-Maintainer Upload?

If the package was fixed on amd64, would you still use it? The package
seems quite popular:

http://qa.debian.org/popcon.php?package=bcrypt

Just because a package is old or dead upstream doesn't mean it is
necessarily removable from Debian - there has to be a problem with the
package on a release architecture (as there is on amd64 currently) or
building from source or using an old lib like gtk1.2 etc.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpTNsy3xEEAG.pgp
Description: PGP signature

Re: Remove a package?

[Kevin Coyner]

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, but got no response. Last update of
> > official site (http://bcrypt.sourceforge.net/) was in September 2002.
> > This program doesn't work and has no support. Is there any reason to
> > keep such packages?
>


I'll be attending to the bug no later than this weekend.

Regards,
Kevin


-- 
Kevin Coyner  GnuPG key: 1024D/8CE11941

Re: remove stale conffiles?

[Adeodato =?iso-8859-1?Q?Sim=F3?=]

* Joerg Sommer [Thu, 05 May 2005 20:39:57 +]:
> Hi,

> in an old version of jed-common two conffiles 00site.sl and 99debian.sl
> were included. But caused by some reason they aren't removed on upgrade.

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266981

> Becomes a conffile held if it was modified when it is removed in a new
> package version?

  If by "held" you mean, "not removed", yes, that's what happens, _even
  if_ the conffile was not modified.

> What does dpkg so with such conffiles they are removed
> from one to the next package version?

  Ignore them, and don't remove them on purge either (since the file is
  no longer a conffile of the package at the version the purge occurs).

  This is a bug in dpkg, see #108587 and its brothers.

> What to do with this bug report? Is this a problem of jed-common?

  Well, if you care you could do something similar to the proposed
  solution for #308252.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Johnny Cash - When the Roll Is Called Up Yon
 
A conclusion is simply the place where someone got tired of thinking.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove an ITP

[Frank Küster]

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 "Vamps Admin ", but this solution does not follow the Debian 
> Policy

Why do you think this would violate the policy?  Of course we must have
a clear indication that the person who put a "This is licensed under
FOO" into the files is actually the one who wrote the code; but I can't
see how this is less or more guaranteed in your case compared to any
freshmeat/sourceforge/whatever download; they don't require to check
your ID card, let alone sign keys or whatever.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Remove bdflush*.deb?

[Guy Maor]

On Wed, 18 Sep 1996, Frank Neumann wrote:

> Now that the bdflush package has been replaced by update - shouldn't the
> binary-/base/bdflush*.deb files be removed for all architectures?
> Or are they still need for reasons I fail to see?

Yes, they should.  Silly of me to forget considering I'm the maintainer
of update.

> (Remember there is no 'bdflush' source package, neither is there an 'update'
> source package - they get created from util-linux).

No, both have their own source packages.


Guy

Re: Remove bdflush*.deb?

[Dominik Kubla]

Frank Neumann wrote:
> Now that the bdflush package has been replaced by update - shouldn't the
> binary-/base/bdflush*.deb files be removed for all architectures?
> Or are they still need for reasons I fail to see?

Just to put things straight:
*  update was replaced by bdflush
*  bdflush is now obsolete because of the kflushd kernel process

Dominik 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The text above represents my personal opinion and does not represent the
official position of my employer on the issue(s) discussed.
Any official statement made on behalf of my employer by me is marked as such.

Re: Remove bdflush*.deb?

[Frank Neumann]

Hi,
Dominik Kubla wrote:

> Just to put things straight:
> *  update was replaced by bdflush
> *  bdflush is now obsolete because of the kflushd kernel process

I _was_ wrong in thinking update and bdflush had no source packages of
their own (thanks, Guy), but I'm pretty sure I'm not wrong in thinking 
it's the other way around (update replacing bdflush :-). Why would otherwise 
the update* files have a much newer stamp date and be uploaded in the new
source format?

Oh well, what the heck,
Frank

Re: remove me from callwave

[Henning Makholm]

Scripsit [EMAIL PROTECTED]

> remove me from callwave [EMAIL PROTECTED]

This is getting as bad as the du*ling b*njos phenomenon.

For some time I just thought that "callwave" must an AOLism for a
discussion forum, and that the posters wanted to unsubscribe from
debian-devel. However, Google does not support this hypothesis.  On
the other hand callwave.com markets something they call an "internet
answering machine", which seems to correlate with the talk of phones
in some of the postings, for example
http://lists.debian.org/debian-devel/2004/08/msg01826.html

Debian-devel is now result number four when googling for "callwave
remove" (without quotes).

I still wonder what the people posting here are thinking, though. If
they are thinking at all, that is.

-- 
Henning Makholm "This imposes the restriction on any
  procedure statement that the kind and type
 of each actual parameter be compatible with the
   kind and type of the corresponding formal parameter."

Re: remove me from callwave

[Bas Zoetekouw]

Hi Henning!

You wrote:

> Debian-devel is now result number four when googling for "callwave
> remove" (without quotes).

Ah, the Duelling Banjos Effect.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 

Re: remove me from callwave

[Ulrich Eckhardt]

On Tuesday 09 November 2004 22:47, Bas Zoetekouw wrote:
> > Debian-devel is now result number four when googling for "callwave
> > remove" (without quotes).
>
> Ah, the Duelling Banjos Effect.
>

Weird, I wouldn't jugde this people capable of using google for solving 
problems their minds can't fathom.

So the mystery 'why?' remains... but maybe that's good, as this world already 
has to few of them left.
: )

Uli

autotools (was Re: Remove cdrtools)

[Bernhard R. Link]

* 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. Real portability involves understanding
> your target systems, learning where the rough edges and corner cases
> are, and developing proper abstractions to work around them.

I do not see how those two things interfere. You have to live with the
differences, so you have to test them. And that autoconf does for you.
What you do with this information is up to the program. You can either
clutter everything with #ifdefs or write some abstraction that fits for
your program and use all the information within there.
Also the article you quoted says that system specific stuff should be
as granular as possible, looking at the specific feature. And that is
exactly what autoconf does. (Which both is one of its biggest advantages
and also accounts for some of its disadvantages like the slowness).

  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remove clamav-unofficial-sigs

[Marco d'Itri]

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 useful as is, so if the alternative is to remove it from the 
archive then I am going to adopt it.

> 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.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Remove clamav-unofficial-sigs

[Paul Wise]

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 great if you could join pkg-clamav and adopt it, as I'm not
particularly interested at this point in time.

Personally I am still waiting for clamav freshclam to properly support
third-party signatures, so clamav-unofficial-sigs can be a config file.

> I have some doubts about the quality of this fork, so I plan to 
> investigate in detail what has changed before blindly adopting it.

I was also unimpressed when I looked at the fork, resulting in me
putting it further down my TODO pile.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Re: Remove clamav-unofficial-sigs

[Mathieu Parent]

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
>> 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 great if you could join pkg-clamav and adopt it, as I'm not
> particularly interested at this point in time.
>
> 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?

>> I have some doubts about the quality of this fork, so I plan to
>> investigate in detail what has changed before blindly adopting it.
>
> I was also unimpressed when I looked at the fork, resulting in me
> putting it further down my TODO pile.

OK

Regards

-- 
Mathieu Parent

Re: Remove clamav-unofficial-sigs

[Paul Wise]

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?

This was an upstream initiative that now appears to be completely
removed from their website. Some references still exist on archive.org
though:

https://wayback.archive.org/web/http://www.clamav.net/lang/en/2011/07/25/clamav-0-97-2-is-now-available/
https://wayback.archive.org/web/http://www.clamav.net/lang/en/download/cvd/3rdparty/

CCing Luca from the clamav project, perhaps he has some news about this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Remove clamav-unofficial-sigs

[Francois Gouget]

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 the si_dbs line commented out in 
00-clamav-unofficial-sigs.conf as suggested last year in: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783228

The SecuriteInfo databases are unusable anyway so there would be nothing 
lost, and this would at least stop the corresponding syslog spam, making 
the rest of the package that much more usable.

And marking bugs 774763 and 784832 as duplicates of 783228 would clean 
things up a bit too and has no reason to block on fixing access to 
SecuriteInfo.

-- 
Francois Gouget   http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene 
Wigner

Re: remove me from call*wave

[John Hasler]

Henning Makholm writes:
> I still wonder what the people posting here are thinking, though.

Probably the same thing as the one who emailed me personally (cc'ing
debian-user) asking for help with his "AO*L a*rt fi*le" problem.
-- 
John Hasler

Re: REMOVE ME FROM CALL WAVE

[Frans Pop]

On Monday 05 September 2005 16:34, [EMAIL PROTECTED] wrote:
> I notified you, electronically a month or more ago to cancel my
> subscription to CALL WAVE.
> This billing has continued on my VISA bill for two or more months.
>
> Will you acknowledge receipt of this current message?  I would like a
> credit memo for the last month or two, but I know this action will not
> be done on your part.  Kill my account if you do nothing else.

Hey! Please get your facts straight.

You are sending your message to an address that _HAS NOTHING TO DO AT ALL_ 
with call wave. So, please look elsewhere and stop spamming us.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM CALL WAVE

[David Pashley]

On Sep 05, 2005 at 15:34, [EMAIL PROTECTED] praised the llamas by saying:
>I notified you, electronically a month or more ago to cancel my
>subscription to CALL WAVE.
>This billing has continued on my VISA bill for two or more months.
> 
>Will you acknowledge receipt of this current message?  I would like a
>credit memo for the last month or two, but I know this action will not be
>done on your part.  Kill my account if you do nothing else.
> 
>Harold C. Fisher
>Phone No. 662-755-8726
>E Mail:   [EMAIL PROTECTED]
> 
>512 Kings Row
>Yazoo City, MS  39194
> 
This list is for developers of Debian GNU/Linux (http://www.debian.org)
and are not related to Callwave in any way.

Please view http://lists.debian.org/debian-devel/2005/01/msg01444.html
for information on how to remove yourself from Callwave.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[John Hasler]

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.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[David Pashley]

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 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 list.

On a side note, I believe that if you are going to follow up, you should
at least be polite. Whilst we may get annoyed with the number of people
asking to be removed, they may not know the extent of the problem and
they will not understand why they get an abusive response. I don't
belive it does the image of Debian any good by sending such replies.

[0] http://lists.debian.org/debian-devel/2005/01/msg01444.html

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[John Hasler]

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 list.

Don't follow up.  Reply to them privately.

> On a side note, I believe that if you are going to follow up, you should
> at least be polite.

Unless you cc them they are not going to see the follow up.  They are not
subscribed.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[David Pashley]

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 that they might find out
> > how to do it themselves rather than emailing the list.
> 
> Don't follow up.  Reply to them privately.

No, because that doesn't help the next person that searches on Google.
> 
> > On a side note, I believe that if you are going to follow up, you should
> > at least be polite.
> 
> Unless you cc them they are not going to see the follow up.  They are not
> subscribed.

I believe I did reply to them.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[Bob Proulx]

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 Debian mailing list it increases the page range on
Google.  That is the problem.

By referencing it here and keeping the Google page rank pointing here
you are actually hurting the users searching Google in the future.

What would help the user would be to increase the page range of
(avoding the name here) in Google so that when they search for it that
Google actually points them to the right place.

Bob


signature.asc
Description: Digital signature

Re: REMOVE ME FROM C4LL W4VE

[David Pashley]

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
> mailing lists in any relation to that search.  Every time someone
> references it in a Debian mailing list it increases the page range on
> Google.  That is the problem.
> 
> By referencing it here and keeping the Google page rank pointing here
> you are actually hurting the users searching Google in the future.
> 
> What would help the user would be to increase the page range of
> (avoding the name here) in Google so that when they search for it that
> Google actually points them to the right place.

Which is exactly why my reply included the link to
http://lists.debian.org/debian-devel/2005/01/msg01444.html so that page
ranks higher than the individual posts from people asking to be removed.
If every time some asks to be removed, we link to that email
in the archive, it will be considered more important than the current
emails that come out top.
> 
> Bob



-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[Benjamin Seidenberg]

-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 mailing lists in any relation to that search. Every time
> someone references it in a Debian mailing list it increases the
> page range on Google. That is the problem.
>
> By referencing it here and keeping the Google page rank pointing
> here you are actually hurting the users searching Google in the
> future.
>
> What would help the user would be to increase the page range of
> (avoding the name here) in Google so that when they search for it
> that Google actually points them to the right place.
>
> Bob


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
dueling banjo's)

Benjamin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHH7Nev9LOsNKpIQRApVFAKCHxXBpqxcZY1yPRu+s5ZzJTy7w7ACeLuSx
MVJeDyiGlNohqvqLfYk8+4g=
=egpV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[John Hasler]

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 believe I did reply to them.

But I did not cc them.  That was my point (I replied privately with an
entirely different message).
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[Bob Proulx]

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
that matched either of those two things.  That would keep them out of
the mailing lists and _eventually_ one would think the page rank would
decrease to the old archives.  Of course that would take someone to do
the work of moderating that particular pattern match.  And at least
someone will contrive an example that matches but is otherwise valid
and complain about it.

Perhaps we should call upon everyone who reads Debian lists to, as
their sacred duty, blog somewhere at least three hits to the upstream
sites as a way to artifically promote them higher?  :-/  (sarcasm)

Bob


signature.asc
Description: Digital signature

Re: REMOVE ME FROM C4LL W4VE

[Richard Atterer]

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[David Pashley]

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 address and spam us.
> 
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.
But yes, I agree that some users are occasionally stupid or lazy or
both. 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.

> 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. :)


> > I believe I did reply to them.
> 
> But I did not cc them.  That was my point (I replied privately with an
> entirely different message).

My apologies, I was not refering to your email, but to the other person
that replied and CCed the list.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[The Fungi]

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 be
more effective to try to get http://www.callwave.com/members/cancel/
bumped up to the top of the google search instead.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[Bob Proulx]

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 problem scanning and faxing with my computer.  I hold the
paper up against the monitor and press "enter" but my computer must
not be able to see it because it does not work.  Can you help me too?

Should I send you a photocopy of the original cdroms that I used to
install on my system?  It is Plan9 will that matter?  I will be sure
to make sure the are the originals that I used because I have heard
that copies of cdroms don't always work.

I am not subscribed so you will need to mail me directly.  And oh by
the way, I also did not include my real address on this message to
avoid getting spam.

Bob


signature.asc
Description: Digital signature

Re: REMOVE ME FROM C4LL W4VE

[John Hasler]

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.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[John Hasler]

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 PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: REMOVE ME FROM C4LL W4VE

[Thomas Bushnell BSG]

[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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove me from call wave

[paddy]

On Thu, Jun 02, 2005 at 08:09:25PM -0500, Heyer Family wrote:
> Please remove me from call wave.
> Thanks

Please see http://wiki.debian.net/?DuelingBanjoes for instructions.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: remove me from call wave

[Andrew Lau]

On Thu, Jun 02, 2005 at 08:09:25PM -0500, Heyer Family wrote:
> Please remove me from call wave.

What part of the email address  looks
like it screams out "we are part of Call Wave"?

Please get your facts straight next time.

Yours sincerely,
Andrew Lau

-- 
---
 Andrew "Netsnipe" Lau  
 Debian GNU/Linux Maintainer & Computer Science, UNSW
 -
  "Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!"
---


signature.asc
Description: Digital signature