Re: Package with non-free build-depends

[Colin Walters]

On Sun, 2002-12-01 at 19:09, Matthias Klose wrote:

> Or else include a "precompiled" version of the docs into your diff
> file.

Hm, I don't think I like this.  The gif images aren't the preferred form
of modification.  Would we accept it if someone had a program written in
a language which only had a non-free compiler, then uploaded source
packages to main which contained object files, and just set
Architecture: i386 ?  I don't think so.

I am sure there is precedent in this area, but I can't think of any
examples offhand.

It seems to me that if it requires non-free software to build, it has to
go into contrib, or you should just drop the images entirely.

Re: KDEE3 question

[Michael Meskes]

On Sat, Nov 30, 2002 at 10:53:40AM +0100, Mateusz Papiernik wrote:
> You're right. Packages from kde.org are very stable, and I think -
> correctly created, I'm using them for long time (about three months),

AFAIK the debian dirs are in KDE cvs anyway.

> and I didn't notice any problems with them. IMO waiting for full gcc
> transition in Sid, which will take very much time, isn't good idea for
> KDE3.

I do agree to that of course. If the gcc 3.2 transition was just a few
days ahead I could understand that, but we haven't got KDE3 for several
months now and still there is not even a plan to move to gcc 3.2 or is
there?

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Package with non-free build-depends

[Josip Rodin]

On Mon, Dec 02, 2002 at 01:09:42AM -0500, Colin Walters wrote:
> > Or else include a "precompiled" version of the docs into your diff
> > file.
> 
> Hm, I don't think I like this.  The gif images aren't the preferred form
> of modification.  Would we accept it if someone had a program written in
> a language which only had a non-free compiler, then uploaded source
> packages to main which contained object files, and just set
> Architecture: i386 ?  I don't think so.

That's the wrong analogy, because images are not programs, they are data.
If I wrote this email in a non-free editor, would you consider the data in
the email non-free just because of that?

-- 
 2. That which causes joy or happiness.

Bug#171419: ITP: libdbix-abstract-perl -- DBI SQL abstraction

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist

* Package name: libdbix-abstract-perl
  Version : 1.003
  Upstream Author : Andrew Turner <[EMAIL PROTECTED]>
* URL : CPAN
* License : Like perl: GPL or Artistic License
  Description : DBI SQL abstraction

 This module provides methods for retrieving and storing data in SQL
 databases.  It provides methods for all of the more important SQL
 commands (like SELECT, INSERT, REPLACE, UPDATE, DELETE).
 .
 It endeavors to produce an interface that will be intuitive to those
 already familiar with SQL.
 .
 Notable features include:
  * data_source generation for some DBD drivers.
  * Can check to make sure the connection is not stale and reconnect if
it is.
  * Controls statement handles for you.
  * Can delay writes.
  * Generates complex where clauses from hashes and arrays.
  * Shortcuts (convenience functions) for some common cases. (Like
select_all_to_hashref.)


 Very helpful IMHO, but I'd like to know if people would use it.  I have
already packaged it for myself so rather take this bugreport/mail as a
vote for wheter this would be a useful addition to the pool or just a
waste of disk space.  If the later I would still keep it in my private
repository.

 Have fun,
Alfie
-- 
tar: Cowardly refusing to create an empty archive

Re: Package with non-free build-depends

[Richard Braakman]

On Mon, Dec 02, 2002 at 12:27:09PM +0100, Josip Rodin wrote:
> > Hm, I don't think I like this.  The gif images aren't the preferred form
> > of modification.  Would we accept it if someone had a program written in
> > a language which only had a non-free compiler, then uploaded source
> > packages to main which contained object files, and just set
> > Architecture: i386 ?  I don't think so.
> 
> That's the wrong analogy, because images are not programs, they are data.
> If I wrote this email in a non-free editor, would you consider the data in
> the email non-free just because of that?

On the other hand, if you change the program, you would like to change
the documentation along with it, yes?  And in an entirely free system,
doing so would either destroy the images or leave them incorrect.
Losing a feature just because you recompile is not the mark of a free program.

Richard Braakman

Procura-se Profissionais!

[Marcia]

Empresa multinacional está contratando interessados com internet, para
trabalhar em período parcial ou integral com altos ganhos.

Se interessar acesse: www.megatrends-on-line.cjb.net
 

Marcia


Nota: Caso não queira mais receber nossas mensagens, retorne este e-mail
com o título: REMOVER.

Re: How to validate Debian woody CDs?

[Richard Atterer]

On Fri, Nov 29, 2002 at 01:35:10PM +0100, Vera Friederichs wrote:
> I have tried several procedures (only with CD2):
[...]
> dd if=/dev/cdrom bs=1k count=8656864 | md5sum

I just noticed that the count is wrong - surely the size of your CD
isn't 8.6 GB? :)

Here are the sizes (in kb) of my 3.0r0 i386 set:

1_NONUS: 662624
  2: 661216
  3: 662656
  4: 656960
  5: 654592
  6: 657760
  7: 354048

> Yes, I checked the README-files. They say it is woody (unofficial,
> but that should not be the problem?)

A mistake was made during the CD generation, so the CDs say they're
unofficial, but they're not.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ '` ¯

Bug#171351: RFA: xmlto -- XML-to-any converter

[Christophe Barbé]

Package: wnpp
Version: unavailable; reported 2002-12-01
Severity: normal

I request an adopter for the xmlto package.

I posted recently about orphaning it on -devel and got a few
answers but nobody adopted it yet. I consider this package important for
debian but feel that I lack sgml and TeX knowledge to package it.

I hope somebody will take care of it. Most bugs (I believe all) are
fixed in the new upstream release. Unfortunately I am unable to get the
last release to produce any output file. The upstream author is helpful
but I am sure I am missing something obvious.

If you want to adopt it, go forward and upload the current package after
closing this RFA bug and changing the maintainer address.

Thanks,
Chistophe

The package description is:
 xmlto is a front-end to an XSL toolchain. It chooses an appropriate
 stylesheet for the conversion you want and applies it using an
 external XSL-T processor. It also performs any necessary
 post-processing.
 Currently the only XSL-T processor that is supported is xsltproc,
 from Daniel Veillard's libxslt package.
 Supported conversions from DocBook XML: dvi, fo, html, html-nochunks,
 man, pdf, ps, txt.
 Supported conversions from XSL-FO: dvi, pdf, ps.
 For DVI, PDF and PostScript output, Sebastian Rahtz's PassiveTeX  is
 required.

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux philly 2.4.20-rc1-ben0 #1 Thu Nov 14 22:18:04 EST 2002 ppc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Package with non-free build-depends

[Josip Rodin]

On Mon, Dec 02, 2002 at 02:55:50PM +0200, Richard Braakman wrote:
> > > Hm, I don't think I like this.  The gif images aren't the preferred form
> > > of modification.  Would we accept it if someone had a program written in
> > > a language which only had a non-free compiler, then uploaded source
> > > packages to main which contained object files, and just set
> > > Architecture: i386 ?  I don't think so.
> > 
> > That's the wrong analogy, because images are not programs, they are data.
> > If I wrote this email in a non-free editor, would you consider the data in
> > the email non-free just because of that?
> 
> On the other hand, if you change the program, you would like to change
> the documentation along with it, yes?  And in an entirely free system,
> doing so would either destroy the images or leave them incorrect.
> Losing a feature just because you recompile is not the mark of a free program.

What _is_ on those images, anyway? I didn't see anyone saying that
recompiling would destroy the images or leave them incorrect.

-- 
 2. That which causes joy or happiness.

Re: How to validate Debian woody CDs?

[Vera Friederichs]

On Mon, 2 Dec 2002 11:49:02 +0100
Richard Atterer <[EMAIL PROTECTED]> wrote:

> On Fri, Nov 29, 2002 at 01:35:10PM +0100, Vera Friederichs wrote:
> > I have tried several procedures (only with CD2):
> [...]
> > dd if=/dev/cdrom bs=1k count=8656864 | md5sum
> 
> I just noticed that the count is wrong - surely the size of your CD
> isn't 8.6 GB? :)
> 

Sorry, I forgot to mount the cdrom before.
But again with
dd if=/dev/cdrom bs=1k count=661216 | md5sum
I get the same result.

Bye,
Vera

pgpbPVcy3k7vG.pgp
Description: PGP signature

Re: Mozilla Calendar?

[Carl B. Constantine]

* Graham Wilson ([EMAIL PROTECTED]) wrote:
> On Sun, Dec 01, 2002 at 08:29:28PM -0800, Carl B. Constantine wrote:
> > If not, I might take it up since I think asd-ng (which I'm supposed to
> > be maintaining) is in limbo at present.
> 
> what is asd-ng?

Advanced Sound Daemon . The idea is to
replace ESounD completely with a better program. But as far as I can
tell, nothing has happened on it for some time.

-- 
 .''`.  Carl B. Constantine
: :' : [EMAIL PROTECTED]
`. `'GnuPG: 135F FC30 7A02 B0EB 61DB  34E3 3AF1 DC6C 9F7A 3FF8
  `-  Debian GNU/Linux -- The power of freedom

Re: Fwd: Please confirm your message

[Jan Niehusmann]

On Sun, Dec 01, 2002 at 08:43:06PM +0100, Russell Coker wrote:
> When you have a very small number of people doing something totally contrary 
> to what everyone else on the Internet is doing, and expecting that everyone 
> else should go out of their way to accomodate them, then you don't need to do 
> any research into who they are.

See it that way: The problem of spam unfortunately is not solved, yet.
There are several approaches to limit the amount of spam, and none of
them is perfect. So, some research is necessary to find better ways of
limiting spam.

And the best way to evaluate some spam filter is to use it. Of course,
that may annoy people, and these people should speak up (because that
adds important information to the evaluation process - a spam filtering
scheme which annoys people too much will not work in the long run). But
please don't take it personal. 

> It is not suitable for individual email addresses.

Time will tell. I fear that some day, the only way to use email
productively is to block all email with invalid sender adresses. And I
don't know a way do valdiate a (not yet known) address but to try it
and send a reply.
If you combine that with some autoresponders on both ends, no human
interaction would be needed, so annoyance should go down.

Jan

Re: Fwd: Please confirm your message

[H. S. Teoh]

On Mon, Dec 02, 2002 at 04:39:30PM +0100, Jan Niehusmann wrote:
[snip]
> Time will tell. I fear that some day, the only way to use email
> productively is to block all email with invalid sender adresses. And I
> don't know a way do valdiate a (not yet known) address but to try it
> and send a reply.
> If you combine that with some autoresponders on both ends, no human
> interaction would be needed, so annoyance should go down.
[snip]

But what if spammers set up autoresponders as well? Just a thought.


T

-- 
What's a "hot crossed bun"? An angry rabbit.

Re: Fwd: Please confirm your message

[Russell Coker]

On Mon, 2 Dec 2002 16:39, Jan Niehusmann wrote:
> > It is not suitable for individual email addresses.
>
> Time will tell. I fear that some day, the only way to use email
> productively is to block all email with invalid sender adresses. And I
> don't know a way do valdiate a (not yet known) address but to try it
> and send a reply.
> If you combine that with some autoresponders on both ends, no human
> interaction would be needed, so annoyance should go down.

If an auto-responder can handle such messages then spammers will just use such 
auto-responders and therefore the spam filter will be almost useless.

Also there's the issue of two people having such filters trying to communicate 
with each other.  NB  You can't just white-list an address when you send mail 
to it as often people don't use the same From: address to reply as they 
advertise when soliciting email (think about [EMAIL PROTECTED] addresses and 
vanity domains).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Last known forwarding address for Jared Johnson?

[Andrew Lau]

Hey everyone,
Can anyone else shed light on fate of Jared "Solomon" Johnson:
International DD of Mystery?

Thanks in advanced,
Andrew "Netsnipe" Lau

- Forwarded message from Erich Schubert <[EMAIL PROTECTED]> -

From: Erich Schubert <[EMAIL PROTECTED]>
To: Andrew Lau <[EMAIL PROTECTED]>
Subject: Re: Last known forwarding address for Jared Johnson?
X-GPG: 4B3A135C 6073 C874 8488 BCDA A6A9  B761 9ED0 78EF 4B3A 135C
X-Eric-Conspiracy: There is no conspiracy
X-Spam-Status: No, hits=-2.9 required=5.0
tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
  SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT
version=2.43
X-Spam-Level: 

I have not heard from him for months now. The only address of him i
remember is <[EMAIL PROTECTED]>, unfortunately.
I'll check my mail archives tonight.

Why has his key been revoked? (Probably because he knew he loses the
mail address?)

He used to sit on IRC in OPN, #debian-devel, nick solomon and/or
solomonwo, but he hasn't been there recently.

Andrew Lau schrieb:
> Dear Eric,
>   I'm trying to get in contact with Jared
> Johnson. <[EMAIL PROTECTED]> is bouncing and his GnuPG key
> 0x5B7CE48E has been revoked and lists no other addresses. I was
> wondering if you have a working forwarding address for him? Thanks in
> advanced.
> 
> Yours sincerely,
> Andrew "Netsnipe" Lau
> 
> PS: In light of Solomon's address bouncing, and the number of NMUs
> already to your name, why don't consider properly hijacking Galeon and
> listing yourself as its Maintainer?

No, i already suggested that the package is orphaned. I don't have time
to further maintain galeon (neither my other packages)

I had been talking to solomon when i started doing the NMUs; he was very
happy by then. I then had to reduce the time i can spend on galeon
(that's why i didn't take over galeon completely by then), but he told
me that he was going to have more free time to spend on galeon soon.
Then he disappeared... I think the last-seen date in db.debian.org
closely matches the time i last saw him, too.

But there have been three people willing to take over maintainance.
(and they've been updating galeon-snapshot recently)
I think they might already have an updated galeon package ready, and
just want to wait for mozilla 1.2.1 (you know the rumors, i guess)

You might just want to ask on debian-devel.

Greetings,
Erich

- End forwarded message -

-- 
---
* Andrew "Netsnipe" LauComputer Science & Student Representaive, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---


pgpt0Cgw1zHFV.pgp
Description: PGP signature

Re: Fwd: Please confirm your message

[Jan Niehusmann]

On Mon, Dec 02, 2002 at 04:58:48PM +0100, Russell Coker wrote:
> On Mon, 2 Dec 2002 16:39, Jan Niehusmann wrote:

> > Time will tell. I fear that some day, the only way to use email
> > productively is to block all email with invalid sender adresses. And I

> If an auto-responder can handle such messages then spammers will just
> use such auto-responders and therefore the spam filter will be almost
> useless.

You are missing the point: That scheme doesn't directly block spam, it
only assures that a mail has a valid Reply-To:-address. Which may (or
may not) stop spam. Time will tell.

> Also there's the issue of two people having such filters trying to
> communicate with each other.

Of course such programs need careful design to prevent loops.

I don't say this is the only solution, I don't even claim it solves the
spam problem at all. But I think it's a sensible experiment. After all,
it may work.

Jan

Re: location of UnicodeData.txt

[Jim Penny]

On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote:
> On Sat, Nov 30, 2002 at 12:35:25PM -0500, Jim Penny wrote:
> 
> > > I think you are missing the points here.
> > > 
> > > First of all, DFSG applied to the standard does not want to change the 
> > > standard, 
> > > but wants all to be able to change the text of the standard.
> > 
> > Huh?  If I change the text of the standard, I have changed the standard!
> 
> No you haven't, only the standards body in question can do that.

The above is in the context of people wanting to be able to change 
the unicode.txt file(s).  This file cannot be changed without producing
something that differs from the standard.  "Correcting" it produces an
artifact that is distinct from the standard.  Is that unclear?

> There are all sorts of reasons why you might wish to create derivative
> works based on the standard -- a new standard for a different purpose, for
> example. 

Derivative works are covered by copyright.  Period.  I would advise that
you not base a defense of infringment of copyright on the fact that you
have only used it to create a derivative work.

> Or helpful documentation of the standard for people who are
> intimidated by the 'dry' nature of the original...

This, on the other hand, would probably be regarded as "fair use",
especially as you would need only illustrative snippets to create such
documentation.  In normal circumstances, embedding the entire table 
in your documentation would likely not be regarded as fair use, but 
that is a fact based pattern that would have to be decided on a case 
by case basis.  In this case, it is arguable that the Unicode
Consortium's license specifically permits inclusion of the entire table,
as it does permit unlimited "extraction".

> 
> > On the other hand,  if you wish to create a competitor to the unicode 
> > standard, say the debicode standard, I see no moral right that you have 
> > to incorporate, without permission, the unicode standard.  You should 
> > expect to start from scratch!
> 
> Engage brain. Do you think that if I want to create a competitor to, say,
> GNU Emacs, that I should expect to have to start from scratch? Or fetchmail?
> Or any one of the thousands of DFSG-free packages that are in main?
> 

Brain engaged.  OK, according to you, anyone can make a competitor to
GNU Emacs and may use the GNU emacs code.  Great.  So, now consider
microsoft visual gnu emacs, which is released under the MS-EULA.  
If that seems to fail to capture your meaning, then well, suppose 
I think that the GPL sucks, and that BSD is the one true license.  
Can I the create FreeOpenBSDGNU emacs with a BSD license (as a
derivative work)?

What's that?  Oh, you mean that anyone may produce a derivative work
that is licensed in a manner compatible with the original work's license,
provided the original license specifically grants that right?  Oh.  Yes, 
I agree with that.  Stated in those terms, it is not much of a surprise.

Now, where in the Unicode license does it give you permission to create
derivative works?  The license does say "Information can be extracted
from these files...".  Oh, and you have to provide "an accompanying notice 
indicating the source".

The license does not say that any of the information in files provided
by the Unicode Consortium can be modified (except by "extraction").
This makes it fail DSFG guideline 3.

> 
> 
> Cheers,
> 
> 
> Nick
> -- 
> Nick Phillips -- [EMAIL PROTECTED]
> Tomorrow will be cancelled due to lack of interest.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: Fwd: Please confirm your message

[Stephen Zander]

> "Jan" == Jan Niehusmann <[EMAIL PROTECTED]> writes:
Jan> Time will tell. I fear that some day, the only way to use
Jan> email productively is to block all email with invalid sender
Jan> adresses. And I don't know a way do valdiate a (not yet
Jan> known) address but to try it and send a reply.  If you
Jan> combine that with some autoresponders on both ends, no human
Jan> interaction would be needed, so annoyance should go down.

The above is based on the false premise that those who send spam are
incapable of sending it with (forged) real email addresses.  They
already have lots of them to choose from.

-- 
Stephen

"A duck!"

Re: Fwd: Please confirm your message

[Jan Niehusmann]

On Mon, Dec 02, 2002 at 08:18:46AM -0800, Stephen Zander wrote:
> The above is based on the false premise that those who send spam are
> incapable of sending it with (forged) real email addresses.  They
> already have lots of them to choose from.

But if they send the spam with a forged email address, the confirmation
request won't be answered. 

(Which needs to be considered when designing a confirmation
auto-responder: It may only confirm messages which were actually sent
from that account)

Jan

PS: I think we are getting off-topic. I am interested in your opinion,
but please consider sending it by private email.

Re: Fwd: Please confirm your message

[Russell Coker]

On Mon, 2 Dec 2002 17:18, Stephen Zander wrote:
> > "Jan" == Jan Niehusmann <[EMAIL PROTECTED]> writes:
>
> Jan> Time will tell. I fear that some day, the only way to use
> Jan> email productively is to block all email with invalid sender
> Jan> adresses. And I don't know a way do valdiate a (not yet
> Jan> known) address but to try it and send a reply.  If you
> Jan> combine that with some autoresponders on both ends, no human
> Jan> interaction would be needed, so annoyance should go down.
>
> The above is based on the false premise that those who send spam are
> incapable of sending it with (forged) real email addresses.  They
> already have lots of them to choose from.

Of course such a spam filter will stop such spam at the cost of doubly 
spamming innocent people who have their addresses forged.

It's very anti-social, zero sum game stuff.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Last known forwarding address for Jared Johnson?

[Mark Howard]

Galeon...

On Mon, 2002-12-02 at 16:10, Andrew Lau wrote:
> But there have been three people willing to take over maintainance.
> (and they've been updating galeon-snapshot recently)
> I think they might already have an updated galeon package ready, and
> just want to wait for mozilla 1.2.1 (you know the rumors, i guess)

Yes. Myself, Bas Zoetekouw <[EMAIL PROTECTED]> and Alex de Landgraaf
<[EMAIL PROTECTED]> have been working on the packages. We are waiting
for the mozilla 1.2.1 release before uploading galeon 1.2.7. 

You might also like to try the galeon 1.3 from the galeon-snapshot
package (updated weekly, when possible). This is the gtk2 rewrite of
galeon, which is now getting quite stable. 
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Last known forwarding address for Jared Johnson?

[Andrew Lau]

Note: <[EMAIL PROTECTED]> also bounces.

-- 
---
* Andrew "Netsnipe" LauComputer Science & Student Representaive, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---


pgpFfLImXwxh0.pgp
Description: PGP signature

Re: Last known forwarding address for Jared Johnson?

[John Goerzen]

On Tue, Dec 03, 2002 at 03:10:09AM +1100, Andrew Lau wrote:
> Hey everyone,
>   Can anyone else shed light on fate of Jared "Solomon" Johnson:
> International DD of Mystery?

I know both the owner of futureks.net and (a bit) Jared.  I'll do some
digging and let you know.

-- John

Re: New maintainer behaviour with NMU and LogJam's hijacking

[Karl Ramm]

Ari Pollak <[EMAIL PROTECTED]> writes:
> I had been taking the full brunt of the responsibility for the 
> xscreensaver NMU, but since I was a pre-NM at the time and sponsors of 
> uploads are supposed to follow Debian policy as well, he ended up taking 
> most of the responsibility. This was a similar situation; however, I felt 
> it was necessary at the time considering the circumstances of the 
> package having not being updated in over a year and a half despite new 
> versions being out which fixed bugs, and the lack of any response from 
> the package maintainer until after the NMU. I still doubt that I would 
> have gotten any response from the maintainer at all had it not been for 
> the actual package upload.

Oh, you're entirely right on that (except for the fact that the time
between the seventh of April nad the eighteenth of July is slightly less
than a year and a half).  At the time, I was tired of explaining to people
that I was ignoring new upstream versions of my packages until woody was
released, and as far as I was concerned, you were just another piece of
spam.  Given that you've spent the time since making the xscreensaver
maintainance job more difficult than it has to be, ignoring you was a
mistake, but I had no way of realizing it at the time.  None of this
changes the fact that I found out about a sponsored NMU of a new upstream
major version with significant changes to the packaging when my own upload
of the same version was rejected.

And at this point, even though I'd *love* to turn xscreensaver maintenance
over to someone I don't like, I still don't think I want you maintaining
something I type my password into on a regular basis until you learn to
play well with others.

kcr

Re: location of UnicodeData.txt

[Jim Penny]

On Sun, Dec 01, 2002 at 11:10:09AM +0100, Bernhard R. Link wrote:
> * Jim Penny <[EMAIL PROTECTED]> [021130 18:43]:
> > Huh?  If I change the text of the standard, I have changed the standard!
> > For example, if I have :
> > 0332;COMBINING LOW LINE;Mn;220;NSM;N;NON-SPACING UNDERSCORE
> > and change this to
> > 0332;NON-COMBINING LOW LINE;Mn;220;NSM;N;SPACING UNDERSCORE
> > Then the standard has been changed!
> > 
> > That is, this file is line after line of character number assignment,
> > followed by character name, (and other information).  There is no
> > possible change that does not change the standard!
> > 
> > Hint: (from standard writer's viewpoint) - A standard that can be
> > changed by anyone, at anytime, without notice and consultation is not
> > a standard, especially if it is a contentious standard that has some
> > people seriously upset (i.e, Russian and XJK users).
> 
> You seem to understand less and less. If the text is changed, it is no
> longer the standard. (A standard can not be changed changing the text,
> as the standard is not a local file, but the unmodified text).

So, can a standard be DSFG free?

> What the licence of a standard file may resonable demand is that no
> changed text pretends to be the unmodified standard.  

They can demand more than that, a lot more.  All of copyright law comes
to bear (if the standard is deemed copyrightable and has been
copyrighted.)  In particular, the owner of a copyright has, unless
waived, control over the right to distribute "derivative works".

> 
> > The text of every standard that I know of is modifiable.  However, it
> > normally takes the consent of the standards body and is issued under
> > its aegis.  Again, Jim Penny's unicode standard has no value, and even
> > debian unicode has very limited appeal.
> 
> You are again talkin of the standard. Not the text of the standard.
> A standard body can issue a new standard. And trademark laws and other
> things can force any new "XYZ standard for UVW" to be issued by some
> special entity.

Look at the file!  UniCode.txt is the core of the standard, it
happens to be an ASCII text file.  So what, every standard is embodied
in text at some point!

You seem to regard standards as some Platonic ideal, completely divorced
from the text which defines them.  This may be a valid viewpoint in some
cases; e.g. the original algol-60 report.  It is not in other cases,
e.g. the algol-68 report.  UniCode.txt is a text file which has no
redundacy and no explanatory text.  There is simply no portion of this
file that can be modified without making an artifact that differs from
the standard in some substantive way.

> 
> > On the other hand,  if you wish to create a competitor to the unicode 
> > standard, say the debicode standard, I see no moral right that you have 
> > to incorporate, without permission, the unicode standard.  You should 
> > expect to start from scratch!
> 
> > Now, IANAL, but I suspect that any unicode editor that reproduced enough
> > information from the unicode standard to be useful would be considered a
> > derived work.  More importantly, I think that is is arguable that this
> > table is, in the terms of the Debian Social Contract,  "necessary for 
> > the execution" of a full unicode editor.  (The language of the debian 
> > Social Contract is even more general and vague than copyright law!
> 
> It talkes about "and to freely use the information supplied in the
> creation of products supporting the UnicodeTM Standard."
> If this does not include making modifications, then jurisdiction is
> more broken then I ever thought. (In my eyes the information should
> even not be copyrightable at all, but this point may be discussed).

The license permits "extraction" of information for "documentation or
programs".  This may be completely different from "modification" or
"correction" of information.

> 
> > In either case, the social contract would place the unicode table into
> > non-free; and any editor that depended on the table, or information
> > derived from the table (in a copyright sense) in either non-free or
> > contrib.
> 
> The table itself may be non-free. I doubt any editor will use the file
> itself but use modification suitable for the program.
> 
> > I have no problem with this result.  But saying that the unicode
> > character table cannot be distributed by debian, in spite of specific
> > language permitting us to do so, seems a bit extreme.  
> 
> If it does not suit for main, then it can not be distributed as part of
> debian. (by definition)

But is can be distributed by debian, not as a part of debian.  That is,
it may be put in non-free, and it may be distributed using the debian
mirrors.  Note:  I did not use the phrase "part of", that is yours.

> 
> > And the
> > consequences of this decision will probably seem extreme to many people.
> > This example just happens to be particularly cogent; there is no doubt
> > it is non-free, there is no dou

Re: location of UnicodeData.txt

[Richard Braakman]

On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote:
> On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote:
> > There are all sorts of reasons why you might wish to create derivative
> > works based on the standard -- a new standard for a different purpose, for
> > example. 
> 
> Derivative works are covered by copyright.  Period.  I would advise that
> you not base a defense of infringment of copyright on the fact that you
> have only used it to create a derivative work.

Umm, yes.  That's exactly why the text of a standard should be free.
You seem to be confusing the "should be" and "is" discussions.
 
> > > On the other hand,  if you wish to create a competitor to the unicode 
> > > standard, say the debicode standard, I see no moral right that you have 
> > > to incorporate, without permission, the unicode standard.  You should 
> > > expect to start from scratch!
> > 
> > Engage brain. Do you think that if I want to create a competitor to, say,
> > GNU Emacs, that I should expect to have to start from scratch? Or fetchmail?
> > Or any one of the thousands of DFSG-free packages that are in main?
> 
> Brain engaged.  OK, according to you, anyone can make a competitor to
> GNU Emacs and may use the GNU emacs code.  Great.  So, now consider
> microsoft visual gnu emacs, which is released under the MS-EULA.  

You seem to have hit the wrong button when you tried to engage your brain.
Why would "create a competitor" have to mean "create a competitor under
a conflicting license"?  The GNU Emacs license allows you to create a
competitor without starting from scratch.  That is what makes it free!

> What's that?  Oh, you mean that anyone may produce a derivative work
> that is licensed in a manner compatible with the original work's license,
> provided the original license specifically grants that right?  Oh.  Yes, 
> I agree with that.  Stated in those terms, it is not much of a surprise.

I don't think he meant that at all.  You're confusing "may" with "should
expect to be able to".   The whole "provided..." clause misses the point.
Laws do not define morality.

Now, why do you think that it would not be a good thing for the text of
the text of the Unicode license to be free?  Your only answer so far
seems to be "because it currently isn't".

Richard Braakman

racoon ISAKMP implementation for IPsec

[Noah L. Meyerhans]

I just downloaded the latest upstream source for the iputils packages
and noticed that they it now contains quite a bit of IPsec code.  In
particular, this includes libipsec and racoon.  Racoon is the KAME
ISAKMP (IPsec key exchange protocol) implementation.  I haven't
investigated further, but considering the upstream author's involvement
in Linux kernel network development, I'd take this as a sign that racoon
will be the "official" ISAKMP implementation for the recently merged
kernel IPsec code.

I haven't seen any mention of racoon on this list, nor in wnpp.  The
iputils release notes indicate that racoon will eventually be moved to a
separate source package that should be packaged separately from the
iptuils Debian packages.  I will maintain the racoon and libipsec
packages, since I haven't seen any sign of other people offering to do
so.

If I missed an ITP, please let me know.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpkBqw0Xy1eM.pgp
Description: PGP signature

Non-DFSG-free package in main

[H. S. Teoh]

I just noticed that 'heyu' is non-free, at least according to bug #149128. 
Shouldn't this bug be upgraded to serious, at least? (We shouldn't be
shipping it in sarge if it's non-free.)


T

-- 
Why is a river rich? 'cos it has two banks.


pgpR5R4ad4PdM.pgp
Description: PGP signature

Re: location of UnicodeData.txt

[Jim Penny]

On Mon, Dec 02, 2002 at 07:30:57PM +0200, Richard Braakman wrote:
> On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote:
> > On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote:
> > > There are all sorts of reasons why you might wish to create derivative
> > > works based on the standard -- a new standard for a different purpose, for
> > > example. 
> > 
> > Derivative works are covered by copyright.  Period.  I would advise that
> > you not base a defense of infringment of copyright on the fact that you
> > have only used it to create a derivative work.
> 
> Umm, yes.  That's exactly why the text of a standard should be free.
> You seem to be confusing the "should be" and "is" discussions.
>  
> > > > On the other hand,  if you wish to create a competitor to the unicode 
> > > > standard, say the debicode standard, I see no moral right that you have 
> > > > to incorporate, without permission, the unicode standard.  You should 
> > > > expect to start from scratch!
> > > 
> > > Engage brain. Do you think that if I want to create a competitor to, say,
> > > GNU Emacs, that I should expect to have to start from scratch? Or 
> > > fetchmail?
> > > Or any one of the thousands of DFSG-free packages that are in main?
> > 
> > Brain engaged.  OK, according to you, anyone can make a competitor to
> > GNU Emacs and may use the GNU emacs code.  Great.  So, now consider
> > microsoft visual gnu emacs, which is released under the MS-EULA.  
> 
> You seem to have hit the wrong button when you tried to engage your brain.
> Why would "create a competitor" have to mean "create a competitor under
> a conflicting license"?  The GNU Emacs license allows you to create a
> competitor without starting from scratch.  That is what makes it free!

The question above did not specify that the competitor was to be GPL
licensed.  In the universe of GPL licensed programs, you are indeed free
to create a competitor using code incorported from GNU emacs; in fact,
the universe of DFSG licenses was specified.  In the universe of DFSG 
licensed programs, you are not free to create a competitor 
using incorporated code, in particular, you cannot create a BSD licensed
version of GNU emacs using derived code. 

(And if BSD licenses were allowed, then so would the MS-EULA license,
by "washing" the GPL through the BSD license.)

> 
> > What's that?  Oh, you mean that anyone may produce a derivative work
> > that is licensed in a manner compatible with the original work's license,
> > provided the original license specifically grants that right?  Oh.  Yes, 
> > I agree with that.  Stated in those terms, it is not much of a surprise.
> 
> I don't think he meant that at all.  You're confusing "may" with "should
> expect to be able to".   The whole "provided..." clause misses the point.
> Laws do not define morality.

This is straying terribly far from field, but are you saying that it is
morally correct that the debian project modify standards without
permission of the standards body?  Or that it is morally correct to
incorporate (portions of) other programs in your work unconditiontally
and without permission of the original creators?  Are you saying that if
the FSF brings a suit alleging GPL violation, that this suit is immoral?

If your answer to any of these is yes, then your morality is very
different from mine.

> 
> Now, why do you think that it would not be a good thing for the text of
> the text of the Unicode license to be free?  Your only answer so far
> seems to be "because it currently isn't".

1) that is a good enough answer to make a determination on whether it is
part of non-free, contrib, or main.

2)  It is an embodiment of years of work by many people who did not
agree that it should be free (in DSFG terms).

3)  I can think of no value in a standard that is DFSG free.  The
purpose of a standard is to ensure interoperability.  If there first has
to be a discovery phase to determine how my "standard" deviates from
your "standard", interoperability is reduced if not destroyed.  

This is not to say that standards should not permit extension.  Most do.
However, even this has been controversial in the past (Microsoft
Kereboros, for example).

Jim Penny

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

Bug#171463: ITP: veejay -- A tracking tool for arranging video samples

[Andrew Lau]

Package: wnpp
Version: unavailable; reported 2002-12-03
Severity: wishlist

* Package name: veejay
  Version : 0.3.2
  Upstream Author : Niels Elburg <[EMAIL PROTECTED]>
* URL : http://veejay.sourceforge.net/
* License : GPL
  Description : A tracking tool for arranging video samples

 VeeJay is a video tracking tool for Linux similar in concept to
 FastTracker (DOS) and ProTracker (Amiga).
 .
 By defining a subset of your video files as one or more samples, you
 can arrange them on tracks in the pattern editor and edit the samples
 to achieve your final goal, the video.  You can then edit the samples
 in the so called Sample Editor, using basic editing tools such as cut,
 copy, paste, crop, and as well as applying a great number of cool
 visual effects.
 .
 Currently only MJPEG is supported with a switch to the Gstreamer
 framework being considered for the distant future. VeeJay comes with
 both a console and GTK+ interface.

==

Preliminary maintainer notes:

This is going to be my largest undertaking for Debian ever. I'm going
to need all the help I can get so willing and enthusiastic
co-maintainers will be welcome.

Christian Marillat, if you're reading this, could you please tell me
if there are any legal reason as to why you haven't uploaded your
MJPEG packages to Debian. Patent/royalties problems? Same thing with
movtar?

Another worry is that veejay is currently very aggressive on
processor-specific optimisations much like mplayer is right now. I'm
going to have a lot of fun trying to convert the i386 - i786 build
time optimisations into runtime detection code/optimisations or
convince upstream to do so. Veejay also supports Alpha and PowerPC
optimisations as well. Oh joy!

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux espresso 2.4.19 #1 Tue Nov 12 23:32:34 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C


-- 
---
* Andrew "Netsnipe" LauComputer Science & Student Representaive, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---


pgpqyckkuGVFE.pgp
Description: PGP signature

I have no package to build error?

[Mateusz Papiernik]

Hi!

I'm trying to build multi-binary package splitted into at least 9 
small packages. After dh_make -m, I've edited debian/control to
something like that:

--cut--
Source: gg2 
Section: main
Priority: optional
Maintainer: Mateusz Papiernik <[EMAIL PROTECTED]>  
Build-Depends: debhelper (>> 3.0.0) 
Standards-Version: 3.5.2 

Package: gg2   
Architecture: any   
Depends: ${shlibs:Depends}
Description: GNU Instant Messenger with plugin support - core
 GNU Gadu 2 is a continuation of GNU Gadu, a Gadu-Gadu
 client. In this release it is plugin based, and all things 
 are in plugins  
 .  
 This is only core of this messenger   

Package: gg2-gadu-gadu  
Architecture: any  
Description: Gadu Gadu plugin for GNU Gadu 2
 Gadu-Gadu protocol plugin for GNU Gadu 2  

Package: gg2-tlen
Architecture: any  
Description: Tlen plugin for GNU Gadu 2
 Tlen protocol plugin for GNU Gadu 2  
--cut--

and the same for other packages. Next in debian I've created:

gg2.dirs
gg2.files 

with main binary

gg2-tlen.dirs
gg2-tlen.files
gg2-gadu-gadu.dirs
gg2-gadu-gadu.files

and other in the same way for plugins
Sample content of that files:

$ cat gg2.files 
usr/bin
$ cat gg2.dirs  
usr/bin
$ cat gg2-tlen.files 
usr/lib/gg2/libtlen_plugin*
$ cat gg2-tlen.dirs  
usr/lib/gg2

I run debuild, and at the end of building, after dh_movefiles
I see:

make[1]: Leaving directory `/home/gohan/debian/gg2/gg2-20021202'
dh_movefiles
dh_testdir -i
dh_testdir: I have no package to build
make: *** [binary-indep] Błąd 1

In debian/gg2-* subdirectories there are all needed files, so
dh_movefiles splitted my package into other as good as he should, so
what's wrong here? What did I do wrong? man dh_testdir don't tell
anything interesting, so what can/should I do to build this package?


hopefuly, there is no documentation of building multi-binary packages in
Developers' Reverence at all, am I right?

-- 
Mati ([EMAIL PROTECTED])
Sounds like a Windows problem, try calling Microsoft support

Re: location of UnicodeData.txt

[Thomas Bushnell, BSG]

Jim Penny <[EMAIL PROTECTED]> writes:

> > There are all sorts of reasons why you might wish to create derivative
> > works based on the standard -- a new standard for a different purpose, for
> > example. 
> 
> Derivative works are covered by copyright.  Period.  I would advise that
> you not base a defense of infringment of copyright on the fact that you
> have only used it to create a derivative work.

The DFSG says that we only use things in Debian where we have been
granted that right.  We think that standards bodies should grant us
that right, and then we will distribute their standard as part of our
system.  If they don't grant us the right, we won't take advantage of
it, and we won't distribute it.  Nobody is infringing any copyrights.

Re: location of UnicodeData.txt

[Thomas Bushnell, BSG]

Jim Penny <[EMAIL PROTECTED]> writes:

> Now, where in the Unicode license does it give you permission to create
> derivative works?  The license does say "Information can be extracted
> from these files...".  Oh, and you have to provide "an accompanying notice 
> indicating the source".
> 
> The license does not say that any of the information in files provided
> by the Unicode Consortium can be modified (except by "extraction").
> This makes it fail DSFG guideline 3.

What about the null extraction, done by using the extraction tool
named "cat"?

Re: location of UnicodeData.txt

[Thomas Bushnell, BSG]

Jim Penny <[EMAIL PROTECTED]> writes:

> This is straying terribly far from field, but are you saying that it is
> morally correct that the debian project modify standards without
> permission of the standards body?  Or that it is morally correct to
> incorporate (portions of) other programs in your work unconditiontally
> and without permission of the original creators?  Are you saying that if
> the FSF brings a suit alleging GPL violation, that this suit is immoral?

I'm saying that

1) It is not *possible* to change the standard without the permission
   of the standards body; 

2) We want the right to be able to distribute properly marked modified
   versions of documents issued by standards bodies (where properly
   marked means adding a notice like "this is not the official
   standard, we changed it");

3) If we don't have the right in (2), it's can't be part of Debian.  I
   happen to think that there is generally no moral problem in
   violating copyrights, but Debian's policy is to honor them.

Re: Non-DFSG-free package in main

[Josip Rodin]

On Mon, Dec 02, 2002 at 01:19:47PM -0500, H. S. Teoh wrote:
> I just noticed that 'heyu' is non-free, at least according to bug #149128. 
> Shouldn't this bug be upgraded to serious, at least?

What are you waiting for? :)

-- 
 2. That which causes joy or happiness.

Re: Fwd: Please confirm your message

[Matthew Garrett]

In chiark.mail.debian.devel, you wrote:
>On Mon, Dec 02, 2002 at 08:18:46AM -0800, Stephen Zander wrote:
>> The above is based on the false premise that those who send spam are
>> incapable of sending it with (forged) real email addresses.  They
>> already have lots of them to choose from.
>
>But if they send the spam with a forged email address, the confirmation
>request won't be answered. 

In order to avoid this, spammers merely have to use a forged from
address that will generate an automatic response. There's no shortage of
those. [EMAIL PROTECTED] springs to mind, and I have no doubt that
there are many others. The spammers can therefore trivially circumvent
the anti-spam measure at no extra cost to themselves, while at the same
time causing even more inconvenience to everyone else. It's a stupid
idea and pandering to people who utilise it only makes things worse for
everyone.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: New maintainer behaviour with NMU and LogJam's hijacking

[Matt Zimmerman]

On Thu, Nov 28, 2002 at 10:54:02PM -0800, [EMAIL PROTECTED] wrote:

> (I am sorry to say I don't know the proper protocol in Debian for this--
> do I file a bug report on the package saying there's a new version?)

This is something that is normally worked out on an individual basis between
the Debian maintainer and upstream maintainer.  A dedicated maintainer will
usually follow the appropriate mailing lists and take care of new versions
without need for any notification.  Some appreciate a simple email reminder.
Some will rarely notice a new version unless someone reports a bug about it.

-- 
 - mdz

Re: How to validate Debian woody CDs?

[Matt Zimmerman]

On Sun, Dec 01, 2002 at 07:35:55PM -0500, Anthony DeRobertis wrote:

> http://http.us.debian.org/dists/woody/Release
> http://http.us.debian.org/dists/woody/main/binary-i386/Packages
> 
> I think debootstrap may even do this verification for you, and you
> mentioned the first CD is known good.

That will only validate the packages on the CD; it contains other important
things (like the installation kernel) which deserve to be validated.

-- 
 - mdz

Bug#171478: ITP: tkabber -- Tcl/Tk based Jabber client

[Jonas Meurer]

Package: wnpp
Version: unavailable; reported 2002-12-02
Severity: wishlist

* Package name: tkabber
  Version : 0.9.2beta
  Upstream Author : Alexey Shchepin <[EMAIL PROTECTED]>
* URL : http://www.jabber.ru/projects/tkabber/
* License : GPL
  Description : Tcl/Tk based Jabber client

Tkabber is a free client for an instant messaging system called Jabber. 
It is written in Tcl/Tk and supports many features like full support of
unicode, ssl support, http proxy, file transfers and support of multi-user
conference protocol.


bye
 mejo

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux jonas 2.4.19 #1 Sun Oct 27 15:23:03 CET 2002 i686
Locale: LANG=C, [EMAIL PROTECTED]

Need other languafes then english, german and french

[Michelle Konzack]

Hello,
Normaly I am using in my~/.baschrc 'export [EMAIL PROTECTED]' and
it works quiet well. Same is for the french users.
The tr_TR is half readable.
Now I like to use setings for 'fs_ IR', 'ar_SY' und 'ar_MA'.
I get a very funny screen... ;-))
Where are the console fonts ???
I have found something for X but nothing for the console...
The most important thing is mc...
Danke fuer die Hilfe
Michelle

Re: location of UnicodeData.txt

[Jim Penny]

On Mon, Dec 02, 2002 at 10:43:42AM -0800, Thomas Bushnell, BSG wrote:
> Jim Penny <[EMAIL PROTECTED]> writes:
> 
> > Now, where in the Unicode license does it give you permission to create
> > derivative works?  The license does say "Information can be extracted
> > from these files...".  Oh, and you have to provide "an accompanying notice 
> > indicating the source".
> > 
> > The license does not say that any of the information in files provided
> > by the Unicode Consortium can be modified (except by "extraction").
> > This makes it fail DSFG guideline 3.
> 
> What about the null extraction, done by using the extraction tool
> named "cat"?
> 

As far as I can tell, this is permitted.  It would not be permitted
under normal copyright law, but the license does permit arbitrary
"extraction".  Extraction of the entirety still appears to be
extraction.  

What the Unicode Consortium does not say is what the distribution rights
are relative to the subsetted tables.   This is a license weakness, but
I suspect that any sane judge would hold that giving permission to do the
extracting implies giving permission to distribute the result.

But, I suspect that any sane judge would also say that extraction for
the purpose of "license laundering" is not implied.  That is, you could
not take the Unicode Consortium's file, apply cat to it, and relicense
the result under BSD (for example).

Now, what is Unicode Consortium really saying here?  They are saying
that you are allowed to use subsets of Unicode.  For example, you may be
interested in only a few languages.  You may select the relevant
portions of the table out.  Or, if you know that you don't care about
bidirectionality, ligation, extenders, grapheme link, or any of the
other various and sundry attibutes, you may drop them.  In other words,
you can do either row or column projection if that is advantageous to
you.  But they clearly do not want you to modify anything, including
character name!  Character name is a searchable field, which some
applications may need.  

Jim Penny


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

Re: racoon ISAKMP implementation for IPsec

[Kyle McMartin]

On Mon, Dec 02, 2002 at 12:34:49PM -0500, Noah L. Meyerhans wrote:
> I haven't seen any mention of racoon on this list, nor in wnpp.  The
> iputils release notes indicate that racoon will eventually be moved to a
> separate source package that should be packaged separately from the
> iptuils Debian packages.  I will maintain the racoon and libipsec
> packages, since I haven't seen any sign of other people offering to do
> so.
> 
I wouldn't imagine so, I doubt anyone has gone to the trouble of porting
racoon to FreeS/WAN's implementation.

Regards,
-- 
Copyleft (c), Kyle McMartin


pgpvwmn7OQ3A9.pgp
Description: PGP signature

Re: Non-DFSG-free package in main

[H. S. Teoh]

On Mon, Dec 02, 2002 at 07:47:18PM +0100, Josip Rodin wrote:
> On Mon, Dec 02, 2002 at 01:19:47PM -0500, H. S. Teoh wrote:
> > I just noticed that 'heyu' is non-free, at least according to bug #149128. 
> > Shouldn't this bug be upgraded to serious, at least?
> 
> What are you waiting for? :)
[snip]

Someone to suggest upgrading it to critical? ;-)


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

Re: I have no package to build error?

[Mateusz Papiernik]

> In debian/gg2-* subdirectories there are all needed files, so
> dh_movefiles splitted my package into other as good as he should, so
> what's wrong here? What did I do wrong? man dh_testdir don't tell
> anything interesting, so what can/should I do to build this package?

OK, now I'm using corrected for gg2 rocks and rules from CBS, and I'm
happy - all is working ok :) Thanks Colin for that system! :)




-- 
Mati ([EMAIL PROTECTED])
Sounds like a Windows problem, try calling Microsoft support

Re: Fwd: Please confirm your message

[Corrin Lakeland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 03 Dec 2002 05:12, Jan Niehusmann wrote:

> You are missing the point: That scheme doesn't directly block spam, it
> only assures that a mail has a valid Reply-To:-address. Which may (or
> may not) stop spam. Time will tell.

But if we can work out that it won't work now, we can save ourselves some time 
and hassle.  Specifically, these autoresponders demand that the spammers 
either validate an email address or use a known good 'from' address.  So they 
will - when spamming someone harvested from debian-devel, they'll set the 
from address to debian-devel.

Personally I think bayesian based spam filters are a godsend.  They're a bit 
naive in places such as being unigram or bigram based, but that'll probably 
get fixed in version two.  And already they are still amazingly good.

Corrin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE9688Zi5A0ZsG8x8cRAomgAJwPEq5gUosw1OjD5EZ8UG7+D/LlvgCdGyiA
Z2//ykiaZqEIeSvClk9B4hc=
=pnwf
-END PGP SIGNATURE-

[no subject]

[Bases de mails]

PUBLICC
SOLUCIONES INFORMATICAS
[EMAIL PROTECTED]

Unicos en el pais 
Nuestros clientes: las empresas mas importantes 
de Argentina, España y Mexico
Reconocidos por los diarios EL CRONISTA COMERCIAL  y 
LA VOZ DEL INTERIOR

Nueva oferta:
Un CD que contiene todos estos datos para realizar publicidad
por e-mail:

20.600 mails Educación (escuelas privadas y estatales
docentes ,universidades ,personal jerárquico, etc) 
 
8.200 mails Industria Gráfica (imprentas ,editoriales
diseñadores, calcografía ,etc) 

90.000 mails  Clase ABC1 (Profesionales , Comerciantes
dueños de empresas, gerentes )  

5.100 mails Empresas con nombre, cuit, teléfono
cantidad de empleados, fax, responsable, cargo, rubro. 

104.000 mails Empresas categorizadas por rubros 

13.300 mails Salud (médicos ,odontólogos ,psicólogos
sanatorios , hospitales, laboratorios ,farmacias)  

14.200 mails  Constructoras ,Arquitectos y Afines 

7.000 mails Medios de comunicación (diarios, radios, revistas, etc)  

4.000 mails  Ferreterías, Buloneras y Pinturerías 
   
15.100 mails  Empresas y Profesionales de la Computación  
 
1.900 mails  Consultoras de RR HH y otras áreas 
 
5.500 mails  Abogados y estudios jurídicos.
   
9.100 mails  Agropecuarios (cooperativas ,productores
estancias ,alimentos ,Ingenieros Agrónomos, veterinarias  
 
16.200 mails Turismo (agencias , hoteles
empresas de transporte ,restaurantes, líneas aéreas ) 
  
42.000 mails Capital Federal (empresas y particulares ,zonificada) 
 
40.000 mails Provincia de Buenos Aires
   
7000 mails Provincia de Córdoba 
(empresas y particulares ,por localidades )   

11000 mails Provincia de Santa Fe
(empresas y particulares ,por localidades ) 

5800 mails   Zona Cuyana 
(Mendoza y San Juan: empresas y particulares ,por localidades )   

11000 mails  Patagonia: (Neuquen, Río Negro, Santa Cruz, Chubut
Tierra del Fuego: empresas y particulares ,por localidades ) 

4000 mails Litoral ( Entre Ríos , Corrientes , Misiones :
empresas y particulares ,por localidades )   

3000 mailsNoroeste  
(Salta , Jujuy , Formosa , Chaco ,La Rioja , Catamarca:
empresas y particulares ,por localidades ) 

3000 mails Centro  (La Pampa , San Luis , Tucumán 
Santiago del Estero: empresas y particulares ,por localidades )

1 mails
Municipios y Organizaciones Gubernamentales  

MAILS DE AMERICA LATINA Y RESTO DEL MUNDO 

5600 mails Bolivia (clasificados por rubros)   
63000 mails Chile (clasificados por rubros con nombres y ciudades) 
235000 mails Brasil (clasificados por rubros)  
35000 mails Centro América (clasificados por rubros) 
24 mails Colombia (clasificados por rubros con nombres y ciudades   
8300 mails Paraguay (clasificados por rubros) 
5500 mails Ecuador (clasificados por rubros)  
28 mails Perú (clasificados por rubros con nombres y ciudades 
11000 mails Uruguay (clasificados por rubros)   
5 mails Venezuela (clasificados por rubros) 
18 mails España (clasificados por rubros)   
467000 mails México (clasificados por rubros) 
65 mails Resto del Mundo (clasificados por países )   
15.000.000 mails Estados Unidos 

SOLICITE YA TODAS ESTAS BASES POR SOLO
   $100

Y ADEMAS  TODO EL SOFTWARE PARA ENVIAR LA PUBLICIDAD.

EN ESTA OPORTUNIDAD OFRECEMOS DE REGALO UN PROGRAMA NUEVO DE ENVIO DE
MAILS QUE OCULTA LA DIRECCION DE IP DE LA MAQUINA REMITENTE.

[EMAIL PROTECTED]

O AL TELEFONO 54 11 4942 0093



Para no recibir mas publicidad:
[EMAIL PROTECTED]

Re: Bug#171351: RFA: xmlto -- XML-to-any converter

[Colin Walters]

On Mon, 2002-12-02 at 09:00, Christophe Barbà wrote:
> Package: wnpp
> Version: unavailable; reported 2002-12-01
> Severity: normal
> 
> I request an adopter for the xmlto package.

Between stuff like this, and our lack of an XML catalog, I'd say that
Debian really needs someone skilled in XML technologies to step forward
and help out.  Is no one out there?

Re: Package with non-free build-depends

[Colin Walters]

On Mon, 2002-12-02 at 06:27, Josip Rodin wrote:
> On Mon, Dec 02, 2002 at 01:09:42AM -0500, Colin Walters wrote:
> > > Or else include a "precompiled" version of the docs into your diff
> > > file.
> > 
> > Hm, I don't think I like this.  The gif images aren't the preferred form
> > of modification.  Would we accept it if someone had a program written in
> > a language which only had a non-free compiler, then uploaded source
> > packages to main which contained object files, and just set
> > Architecture: i386 ?  I don't think so.
> 
> That's the wrong analogy, because images are not programs, they are data.
> If I wrote this email in a non-free editor, would you consider the data in
> the email non-free just because of that?

Er...any editor (and there are plenty of free ones in main) can edit the
data in your email, and if you put it under a free license, then I'd be
perfectly happy.  The "source" is the data itself.

In contrast, the "source" for the gifs is not the same as the gifs, and
they can only be currently produced by a non-free program.  I think the
analogy is clear:

.gif <-> object code
docs <-> source code
dot <-> gcc

It seems to me that if we allow this precedent to be set, it's just a
little bit farther to allowing object files in source packages.  Maybe
what we need to do is have a rule that Debian source packages must be in
the "preferred form" of modification.

I think that if we had such a rule, it would be a good thing.  One thing
I have seen some people do (and I've done in the past), is modify a
package's Makefile.am to say add a file, run automake to get the
Makefile.in, and then just include the Makefile.in patch in their Debian
diff.  The reason I didn't include the Makefile.am modifications in the
diff was to prevent automake from being rerun during the build (due to
file timestamp issues).  But the patch against the Makefile.in isn't the
"preferred form" of modification; the one against the Makefile.am is,
but it's not included in the source package I uploaded to Debian.  So if
someone else later needs to do something further with my modifications,
they're kind of screwed.  Since then I've been including both the
Makefile.in and Makefile.am patches in the Debian diff, and I've taken
other steps to ensure automake wasn't rerun at build time.

Now, I'm not sure where we would list such a rule about source packages
and preferred modification form; it doesn't really seem to belong in the
Social Contract or the DFSG.  It mostly just seems like "common sense";
but it's easy to violate it in little ways, and those set precedents for
bigger ways.

Re: Bug#171463: ITP: veejay -- A tracking tool for arranging video samples

[Colin Walters]

On Mon, 2002-12-02 at 12:47, Andrew Lau wrote:
> Package: wnpp
> Version: unavailable; reported 2002-12-03
> Severity: wishlist
> 
> * Package name: veejay
>   Version : 0.3.2
>   Upstream Author : Niels Elburg <[EMAIL PROTECTED]>
> * URL : http://veejay.sourceforge.net/
> * License : GPL
>   Description : A tracking tool for arranging video samples
> 
>  VeeJay is a video tracking tool for Linux similar in concept to
>  FastTracker (DOS) and ProTracker (Amiga).

Your description looks good to me, except I would drop the "for Linux",
since it's redundant, and would look silly when browsed from a Debian
GNU/FreeBSD machine...

Re: Bug#171463: ITP: veejay -- A tracking tool for arranging video samples

[Matt Zimmerman]

On Mon, Dec 02, 2002 at 05:21:09PM -0500, Colin Walters wrote:

> On Mon, 2002-12-02 at 12:47, Andrew Lau wrote:
> >  VeeJay is a video tracking tool for Linux similar in concept to
> >  FastTracker (DOS) and ProTracker (Amiga).
> 
> Your description looks good to me, except I would drop the "for Linux",
> since it's redundant, and would look silly when browsed from a Debian
> GNU/FreeBSD machine...

Except that it uses v4l, which I believe at this point does make it "for
Linux".

-- 
 - mdz

Re: Need other languafes then english, german and french

[Osamu Aoki]

On Mon, Dec 02, 2002 at 08:37:58PM +0200, Michelle Konzack wrote:
> Hello,
> 
> Normaly I am using in my~/.baschrc 'export [EMAIL PROTECTED]' and
> it works quiet well. Same is for the french users.
> 
> The tr_TR is half readable.
> 
> Now I like to use setings for 'fs_ IR', 'ar_SY' und 'ar_MA'.
> 
> I get a very funny screen... ;-))
... 
> The most important thing is mc...

If issue is mc, why not start mc with "-a" option.  It let mc use only 
ascii codes to draw frame etc. 

Good luck

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]>   Cupertino CA USA, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract

Re: Fwd: Please confirm your message

[Brian May]

On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote:
> Personally I think bayesian based spam filters are a godsend.  They're a bit 
> naive in places such as being unigram or bigram based, but that'll probably 
> get fixed in version two.  And already they are still amazingly good.

Are these packaged for Debian?

Where can I find more information?
-- 
Brian May <[EMAIL PROTECTED]>

Re: location of UnicodeData.txt

[Thomas Bushnell, BSG]

Jim Penny <[EMAIL PROTECTED]> writes:

> But, I suspect that any sane judge would also say that extraction for
> the purpose of "license laundering" is not implied.  That is, you could
> not take the Unicode Consortium's file, apply cat to it, and relicense
> the result under BSD (for example).

Sure, but nobody is proposing any kind of "license laundering".

Bug#171497: ITP: xdoclet -- XDoclet is an extended Javadoc Doclet engine

[Joe Phillips]

Package: wnpp
Version: N/A; reported 2002-12-02
Severity: wishlist

* Package name: xdoclet
  Version : 1.1.2
  Upstream Author : XDoclet Developers 
* URL : http://xdoclet.sourceforge.net/
* License : GPL
  Description : XDoclet is an extended Javadoc Doclet engine


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux archaeopteryx 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
Locale: LANG=en.ISO-8859-1, LC_CTYPE=en_US

Bug#171496: ITP: ggi-doc -- General Graphics Interface Documentation

[Martin Albert]

Package: wnpp
Version: N/A; reported 2002-12-02
Severity: wishlist

* Package name: ggi-doc
  Version : 0.0.20021202
  Upstream Author : Julin, Egger, Faurot, Cheng
* URL : http://www.ggi-project.org/
* License : see below
  Description : General Graphics Interface Project Documentation

  This is the complete HTML documentation to various aspects and
  libraries of the GGI project as it can be found on their website.
  Some of the libraries have already been packaged (libgii, libggi,
  libggimisc), some are yet to come ... ;)

  License
   Permission is hereby granted, free of charge, to any person obtaining
   a copy of this software and associated documentation files (the
   "Software"), to deal in the Software without restriction, including
   without limitation the rights to use, copy, modify, merge, publish,
   distribute, sublicense, and/or sell copies of the Software, and to
   permit persons to whom the Software is furnished to do so, subject to
   the following conditions:

   The above copyright notice and this permission notice shall be
   included in all copies or substantial portions of the Software.
 

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux lovemachine 2.4.18 #1 Fri Jun 28 16:40:03 UTC 2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: Bug#171463: ITP: veejay -- A tracking tool for arranging video samples

[John Goerzen]

On Mon, Dec 02, 2002 at 05:21:09PM -0500, Colin Walters wrote:
> >   Description : A tracking tool for arranging video samples
> > 
> >  VeeJay is a video tracking tool for Linux similar in concept to
> >  FastTracker (DOS) and ProTracker (Amiga).
> 
> Your description looks good to me, except I would drop the "for Linux",
> since it's redundant, and would look silly when browsed from a Debian
> GNU/FreeBSD machine...

Actually, it's a bad description.  It says nothing about what it is to
someone that has not used FastTracker or ProTracker.  It should explain what
it does.  (ie, "ls shows a listing of files in a directory" instead of "ls
is a Linux command similar to dir")

Re: Fwd: Please confirm your message

[Jonathan Oxer]

On Tue, 2002-12-03 at 09:53, Brian May wrote:
> On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote:
> > Personally I think bayesian based spam filters are a godsend.  They're a 
> > bit 
> > naive in places such as being unigram or bigram based, but that'll probably 
> > get fixed in version two.  And already they are still amazingly good.
> 
> Are these packaged for Debian?
> 
> Where can I find more information?

apt-get install bogofilter
http://www.tuxedo.org/~esr/bogofilter/
http://www.paulgraham.com/spam.html

Works like a ripper, I've primed it with a 2000 message spam corpus and
10,000 message non-spam, and it gets called by procmail. Very high
accuracy, very few (approaching 0) false positives and negatives.

Jonathan Oxer
Ph +61 3 9723 9399 / Fx +61 3 9723 4899
GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg


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

Re: Fwd: Please confirm your message

[Craig Dickson]

Brian May wrote:

> On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote:
> > Personally I think bayesian based spam filters are a godsend.  They're a 
> > bit 
> > naive in places such as being unigram or bigram based, but that'll probably 
> > get fixed in version two.  And already they are still amazingly good.
> 
> Are these packaged for Debian?

dpkg -p bogofilter

apt-cache search Bayes

> Where can I find more information?

Google is your friend. This is the first thing it finds for "Bayesian
spam filter" -- the article that got the whole idea going in the first
place:

http://www.paulgraham.com/spam.html

Craig

Re: Bug#171463: ITP: veejay -- A tracking tool for arranging video samples

[Colin Walters]

On Mon, 2002-12-02 at 17:37, Matt Zimmerman wrote:
> On Mon, Dec 02, 2002 at 05:21:09PM -0500, Colin Walters wrote:
> 
> > On Mon, 2002-12-02 at 12:47, Andrew Lau wrote:
> > >  VeeJay is a video tracking tool for Linux similar in concept to
> > >  FastTracker (DOS) and ProTracker (Amiga).
> > 
> > Your description looks good to me, except I would drop the "for Linux",
> > since it's redundant, and would look silly when browsed from a Debian
> > GNU/FreeBSD machine...
> 
> Except that it uses v4l, which I believe at this point does make it "for
> Linux".

OK, good point.  I agree.

Re: Fwd: Please confirm your message

[Duncan Findlay]

On Tue, Dec 03, 2002 at 09:53:56AM +1100, Brian May wrote:
> On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote:
> > Personally I think bayesian based spam filters are a godsend.  They're a 
> > bit 
> > naive in places such as being unigram or bigram based, but that'll probably 
> > get fixed in version two.  And already they are still amazingly good.
> 
> Are these packaged for Debian?

The CVS version of SpamAssassin has a Bayesian type component to it.
The latest CVS packages are available (and built daily by 10:00 UTC):

deb http://people.debian.org/~duncf/debian/ unstable main

Or you can wait till SpamAssassin 2.50 is released. Your call. IMHO,
Spamassassin is better than purely bayes based filters since it only
uses bayes as one component of the score, and uses many other rules to
determine the overall level of spamminess.
 
> Where can I find more information?

http://www.spamassassin.org/

-- 
Duncan Findlay

Re: Package with non-free build-depends

[Olaf Meeuwissen]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Mon, Dec 02, 2002 at 02:55:50PM +0200, Richard Braakman wrote:
> > > > Hm, I don't think I like this.  The gif images aren't the preferred form
> > > > of modification.  Would we accept it if someone had a program written in
> > > > a language which only had a non-free compiler, then uploaded source
> > > > packages to main which contained object files, and just set
> > > > Architecture: i386 ?  I don't think so.
> > > 
> > > That's the wrong analogy, because images are not programs, they are data.
> > > If I wrote this email in a non-free editor, would you consider the data in
> > > the email non-free just because of that?
> > 
> > On the other hand, if you change the program, you would like to change
> > the documentation along with it, yes?  And in an entirely free system,
> > doing so would either destroy the images or leave them incorrect.
> > Losing a feature just because you recompile is not the mark of a free 
> > program.
> 
> What _is_ on those images, anyway? I didn't see anyone saying that
> recompiling would destroy the images or leave them incorrect.

>From the doxygen documentation:

Doxygen uses the "dot" tool to generate the following graphs:

* if GRAPHICAL_HIERARCHY is set to YES, a graphical representation
  of the class hierarchy will be drawn, along with the textual
  one. Currently this feature is supported for HTML only.
  Warning: When you have a very large class hierarchy where many
  classes derive from a common base class, the resulting image may
  become too big to handle for some browsers.

* if CLASS_GRAPH is set to YES, a graph will be generated for each
  documented class showing the direct and indirect inheritance
  relations. This disables the generation of the built-in class
  inheritance diagrams.

* if INCLUDE_GRAPH is set to YES, an include dependency graph is
  generated for each documented file that includes at least one
  other file. This feature is currently supported for HTML and RTF
  only.

* if COLLABORATION_GRAPH is set to YES, a graph is drawn for each
  documented class and struct that shows:

  o the inheritance relations with base classes.
  o the usage relations with other structs and classes
(e.g. class A has a member variable m_a of type class B,
then A has an arrow to B with m_a as label).

HTH,
-- 
Olaf MeeuwissenEPSON KOWA Corporation, ECS
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
Penguin's lib!   -- I hack, therefore I am --   LPIC-2

FW: Re: FW: Last known forwarding address for Jared Johnson?

[John Goerzen]

Here is the info.

- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Date: Mon, 2 Dec 2002 17:35:45 -0600 (CST)
To: [EMAIL PROTECTED]
Subject: Re: FW: Last known forwarding address for Jared Johnson?

Jared has been without Internet access for several months now.

Any of his packages I'm sure could be taken over on a permanent basis by
someone else.  If someone absolutely needs to get in touch with him, a
message can be forwarded to me, and I'll pass it to him in person, or you
can reach him by phone at [deleted -- jgoerzen].
-- Jonathan


> - Forwarded message from Andrew Lau <[EMAIL PROTECTED]>
> -
>
> From: Andrew Lau <[EMAIL PROTECTED]>
> Date: Tue, 3 Dec 2002 03:10:09 +1100
> To: debian-devel@lists.debian.org
> Subject: Last known forwarding address for Jared Johnson?
>
> Hey everyone,
>   Can anyone else shed light on fate of Jared "Solomon" Johnson:
> International DD of Mystery?
>
> Thanks in advanced,
> Andrew "Netsnipe" Lau
>
> - Forwarded message from Erich Schubert <[EMAIL PROTECTED]> -
>
> From: Erich Schubert <[EMAIL PROTECTED]>
> To: Andrew Lau <[EMAIL PROTECTED]>
> Subject: Re: Last known forwarding address for Jared Johnson?
> X-GPG: 4B3A135C 6073 C874 8488 BCDA A6A9  B761 9ED0 78EF 4B3A 135C
> X-Eric-Conspiracy: There is no conspiracy
> X-Spam-Status: No, hits=-2.9 required=5.0
>   tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
> SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT
>   version=2.43
> X-Spam-Level:
>
> I have not heard from him for months now. The only address of him i
> remember is <[EMAIL PROTECTED]>, unfortunately.
> I'll check my mail archives tonight.
>
> Why has his key been revoked? (Probably because he knew he loses the
> mail address?)
>
> He used to sit on IRC in OPN, #debian-devel, nick solomon and/or
> solomonwo, but he hasn't been there recently.
>
> Andrew Lau schrieb:
>> Dear Eric,
>>  I'm trying to get in contact with Jared
>> Johnson. <[EMAIL PROTECTED]> is bouncing and his GnuPG key
>> 0x5B7CE48E has been revoked and lists no other addresses. I was
>> wondering if you have a working forwarding address for him? Thanks in
>> advanced.
>>
>> Yours sincerely,
>> Andrew "Netsnipe" Lau
>>
>> PS: In light of Solomon's address bouncing, and the number of NMUs
>> already to your name, why don't consider properly hijacking Galeon and
>> listing yourself as its Maintainer?
>
> No, i already suggested that the package is orphaned. I don't have time
> to further maintain galeon (neither my other packages)
>
> I had been talking to solomon when i started doing the NMUs; he was
> very happy by then. I then had to reduce the time i can spend on galeon
> (that's why i didn't take over galeon completely by then), but he told
> me that he was going to have more free time to spend on galeon soon.
> Then he disappeared... I think the last-seen date in db.debian.org
> closely matches the time i last saw him, too.
>
> But there have been three people willing to take over maintainance.
> (and they've been updating galeon-snapshot recently)
> I think they might already have an updated galeon package ready, and
> just want to wait for mozilla 1.2.1 (you know the rumors, i guess)
>
> You might just want to ask on debian-devel.
>
> Greetings,
> Erich
>
> - End forwarded message -
>
> --
> ---
> * Andrew "Netsnipe" LauComputer Science & Student Representaive,
> UNSW * *   # apt-get into itDebian GNU/Linux Package 
> Maintainer
> * *   
> * * GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D
> 2E8B 68BD *
> ---
>
>
>
> - End forwarded message -




- End forwarded message -

-- 
John Goerzen <[EMAIL PROTECTED]>   www.complete.org

Gentoo thread post-mortem

[Camm Maguire]

Greetings!  I just saw the Gentoo thread reported on DWN.  Please
excuse the lateness of this suggestion -- I hope it will be worth your
attention.  

In my opinion, we should make sure to get the *very large* performance
gains (e.g. ~ >=50%) available through subarch package tuning, and
leave the 5-20% gains for later if we ever have time.  In my
experience, such gains are available in a very few well-defined areas
of computation -- floating point linear algebra, perhaps random
number generation and hashing, multiple precision arithmetic, etc.  I
think that we should

1) identify no more than 20 such areas
2) isolate the performance critical code in shared libraries, and
3) rely on the dynamic loader and its configuration to load the most
optimal version at runtime.

blas/lapack/atlas already does this, to great performance benefit,
which is then immediately available to all programs linking against
blas/lapack without further re-compilation.  there are currently quite
a few of these programs in Debian.

I put this together into a policy proposal last year, but it seems to
have foundered:

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

Comments/action on this proposal would be most appreciated!

Take care,

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: New maintainer behaviour with NMU and LogJam's hijacking

[Ari Pollak]

And I'm sure everyone really appreciates that kind of arrogance. You've 
just exemplified the very reason why people aren't burning effigies of 
me at the moment. Last time I checked (unless I'm completely off here), 
users much preferred real progress over pretentious bureaucracy. I 
really don't care whether you want to give over maintainership to 
anyone, and me making the NMU was never meant to influence that even in 
the slightest, and I don't deny that it was wrong to rush an upload of 
xscreensaver like that. In the meantime, people seem to be perfectly 
happy with the packages I do maintain.

Effort. It's a wonderful thing.

P.S. I was referring to LogJam not being updated in a year and a half.

> And at this point, even though I'd *love* to turn xscreensaver
> maintenance over to someone I don't like, I still don't think I want 
> you maintaining something I type my password into on a regular basis
> until you learn to play well with others.

Re: [Agnubis] Packaging Agnubis for Debian GNU/Linux

[Steve Langasek]

On Fri, Nov 29, 2002 at 02:08:50PM +0100, Amaya wrote:
> Andrew Lau dijo:
> > Does this offer sound fair to you?

> He doesn't need to be a Developer (or even want to become one) in order
> to package Agnubis. 

This is not a canonical interpretation, at least if by "to package
Agnubis" you mean "to maintain an Agnubis package for Debian".  I've seen
it stated in the past that the sponsorship program exists to help non-DDs
get their packages uploaded *while they are in the NM queue*, meaning
that someone who is not interested in becoming a DD should also not be
trying to maintain packages.

-- 
Steve Langasek
postmodern programmer


pgplgQft04X2Z.pgp
Description: PGP signature

Re: Bug#171351: RFA: xmlto -- XML-to-any converter

[Graham Wilson]

On Mon, Dec 02, 2002 at 05:16:20PM -0500, Colin Walters wrote:
> On Mon, 2002-12-02 at 09:00, Christophe Barb?? wrote:
> > Package: wnpp
> > Version: unavailable; reported 2002-12-01
> > Severity: normal
> > 
> > I request an adopter for the xmlto package.
> 
> Between stuff like this, and our lack of an XML catalog, I'd say that
> Debian really needs someone skilled in XML technologies to step
> forward and help out.  Is no one out there?

i intend to adopt xmlto. i am not overly skilled (nor underly, though)
in xml, but if someone else who *is* overly skilled with xml would like
to adopt, please do.

--
gram


pgpdlkVUWPgr6.pgp
Description: PGP signature

河北最大的电子商务网------华北商务网。

[华北商务网]

Title: 华北商务网


全面展开你的网络营销--华北商务网


   
   

  
 
 
   

  
   

  

 
   
   
您好：
  　　华北商务网是一新建的B2B的电子商务网站，新增华北纺织服装网、华北食品网、华北酒类网，为您提供了更好的服务。
  　　华北商务网旨在协助企业以最小的投入实现最强的网络功能，加速企业信息化的进程；
  　　华北商务网是企业发布产品销售和采购信息、完成网上交易、实现产销管理、展示企业形象、展示企业精品的平台，是获得经济信息、政策信息、商务信息的综合信息服务网络。
  　　华北纺织服装网：http://fuzhuang.hbeb.com
  　　华北食品网：http://shipin.hbeb.com
  　　华北酒类网：http://jiu.hbeb.com
  　　如果此信给您带来不便,我们深感抱歉
  
  网址:http://www.hbeb.com
  电话:0311-3038784
  联系人:徐小姐
  
  顺祝商祺
  

 
  

  
  
  
 
  
 
 
  

 
   

  

 
  

 
   

   
   
 
 
 
  
   
 
 
 
  
   

  


 
  

  
   

Re: location of UnicodeData.txt

[David Starner]

> But they clearly do not want you to modify anything, including
> character name!  Character name is a searchable field, which some
> applications may need.  

It's an English field, for which there is a canonical translation
for French, and there should be translation for other languages.

> The only overlap with any previous character coding is the first 127
> characters (ASCII).

Nope. There's massive overlap with previous character codings on 
all sorts of levels. The first 256 characters are Latin-1; the 
Greek block is a superset of ISO-8859-7 (that is, the characters 
are in the same order, but some of the gaps have been filled in), 
as is Cyrillic and Arabic for their respective 8859 standard. All 
the Indian blocks are weird echos of ISCII. The basic CJK block is 
the ideographs from the preexisting Chinese, Japanese and Korean 
standards, sorted by the order of traditional dictionaries like the 
KangXi.

> If a system simply declared a section of data to be
> UniCode data, and made no attempt to comprehend the contents, it
> probably would not need to have access to the contents of Unicode.txt.

Just like if a system simply declared a section of data to be
code complaint to Fortran-2026, and if it made no attempt to
comprehend it, it wouldn't need access to the contents of that
standard. A text-processing program that needs to display data is 
going to need the contents of UnicodeData for BiDi. A proper
cut program should use UnicodeData, so it doesn't seperate a 
character from a subsequent combining character. A spell program 
is going to need the data to know which characters end words. 
Anything that handles text in a way more complex then cat will
access to this data.

__
Do you want a free e-mail for life ? Get it at http://www.personal.ro/

Welcome!

[coolbiao]

Title: 我们是国内唯一的Swatch网上邮购站



风靡世界
的瑞士Swatch时尚表就在您身边
　

   您若是处于大城市时尚前沿的表迷或工作紧张的白领，通过我们，您就能足不出户买到心中
所爱，免除上街购物的劳顿和麻
烦，同时节约出宝贵的时间。

   您若居住在中小城镇，正苦于找不到Swatch专卖店
，通过我们和遍布全国的邮政网路，您也可以在当地超前进入时尚一族的
行列。

   您若是企业或商家的经理或老板，通过我们，
您一定能为自己的产品挑选到最佳的促销抽奖奖品，我们会为您提供一切可能
的方便。

   
您若正准备向情侣爱人、亲朋好友或任何有求之人馈赠纪念品或送礼，选购我
们这里的流行款式，收受方一定会
体会到您的真诚；因为人人皆知，Swatch是世界上最货真价实和具有艺
术含量的商品之一！
　
您若是收
藏家，那就请到我们这里来为自己的藏品补缺
吧！Swatch像邮票一样，层出不穷，
季季翻新，限量、断档和绝版的品种随时可见，一旦气候形成，某些款式的身
价会直上云霄！那就要看您的眼力
了。
　
　
欢迎光临
  Swatch郑州专柜网上超市