Re: Bug#457384: ITP: netsend -- a speedy filetransfer and network diagnostic program

[Hagen Paul Pfeifer]

* Ron Johnson | 2007-12-22 13:01:44 [-0600]:

>Then would it be helpful to specify in the long descrip that it's 
>main purpose is Linux<->Linux transfers?

Why not. Martin, it is up to you to edit these lines ... ;-)

HGN


-- 
Hagen Paul Pfeifer <[EMAIL PROTECTED]>  ||  http://jauu.net/
Telephone: +49 174 5455209   ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
Always in motion, the future is. 


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Turbo Fredriksson]

Quoting "Leo \"costela\" Antunes" <[EMAIL PROTECTED]>:

> Please note that I don't personally like Qmail either, but I still think
> we should (but don't *have* to) provide it, if possible (I don't know
> what's the outcome of the "putting it in public domain" story).

Why was it removed from Debian GNU/Linux in the first place!?

And when? I didn't even know that it was gone untill I saw this thread.
Although I don't use the official package (I need the LDAP patches),
my own packages is based on the official package though...


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Kalle Kivimaa]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:
> Why was it removed from Debian GNU/Linux in the first place!?

It's never been in Debian. The source package is in non-free, as the
license didn't permit binary distribution. See e.g.
http://packages.debian.org/etch/qmail-src for some explanation.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Which spell checkers to include by default?

[Bernhard R. Link]

* Petter Reinholdtsen <[EMAIL PROTECTED]> [071222 20:22]:
> > Note that the w* packages provide word lists, which are important to
> > many programs.  One could argue that a standard Unix system should
> > have a word list; at least, every Unix system I have used provides
> > one.
> 
> OK.  Which programs?  I was only aware of ispell.

I thought ispell would only use the i* packages and not the w* packages.
To enhance the list of packages needing w* packages, the cracklib
packages (like libpam-cracklib) also use it to make sure you are not
using a known word as password.

Hochachtungsvoll,
Bernhard R. Link


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

Re: wxwidgets 2.8, anyone?

[Bernd Zeimetz]

> If there was someone else really prepared to do a better
> job with this than I seem to have done, they'd have naturally taken
> over as the primary maintainer a long time ago. 

Really? Ron, you're crying hijacking whenever somebody else tried to
touch wx. If upstream breaks the API/ABI at random times, it's your job
as maintainer to do something against it, together with upstream. If you
can't work together with upstream for private reasons, it's time to give
the package to somebody else.

I'd suggest the following plan to get rid of this *stupid* discussion:

1. Get wx2.4 out of the archive _soon_. There's a list in wiki.d.o about
the status of the last applications using wx2.4, if I remember right.
Their maintainers had more than enough time to et them migrated to 2.6
(or 2.8, if there would be 2.8).
2. Move the packaging in a team, put the _team_ as maintainer, and
choose one DD who is not involved with wx to review and handle uploads,
this should avoid stupid discussions between the team members about what
to upload, and when and other blahblah.
3. As more and more programs and upstreams demand 2.8, especially from
the Python point of view, package 2.8 in the team _soon_, so it can get
into Lenny. Or get 3.0 released _now_. Ubuntu ships 2.8 for a long time
now, so looking into their bugtracker to learn about bugs in 2.8 would
be a good start, also looking at their patches is probably (*sigh*, we
know how Ubuntu patches are sometimes...) a good thing. My personal
opinion of wx is not a very good one, and I can partly understand Ron's
point of view, but it's code so it is fixable by good maintainers.

If the WX problem is not solved until NYE, I'd suggest to take it to the
tech-ctte, so somebody with an independent point of view can decide if
2.8 should/needs to be shipped with Lenny.


Best regards,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: etch ftp-mirror broken?

[Chris Lamb]

Henning Glawe wrote:

> seems like something went wrong during the etch 4.0r1 update on the ftp
> mirrors: the old etch kernel packages got removed from the archive, but are
> still referenced in the package lists.

This has already been reported as #455089.


Regards,

/Lamby

[0] http://bugs.debian.org/455089

-- 
Chris Lamb, UK   [EMAIL PROTECTED]
GPG: 0x634F9A20


signature.asc
Description: PGP signature

Re: Bug#457384: ITP: netsend -- a speedy filetransfer and network diagnostic program

[brian m. carlson]

On Sat, Dec 22, 2007 at 07:16:20PM +0100, Hagen Paul Pfeifer wrote:

* Ron Johnson | 2007-12-21 21:30:08 [-0600]:

From reading the web page, it seems that netsend might only work 
between Linux systems.  Am I reading it wrong?


You are right. Netsend is optimized for linux: splice(), madvice(), congestion
control algorithms (bic, cubic, ...), etc. There is currently no plan to port
it for other operating systems, there is currently no demand.


As someone who occasionally uses GNU/kFreeBSD, I would then ask you to 
please set the Architecture field appropriately; that is, please don't 
set it to "all", unless you want a bug (and porting help).


Also, madvise(2) is apparently BSD, and even if it's not, it can be 
substituted with posix_madvise(2).  So if splice is the only system call 
that isn't portable, it should probably be easy to port.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

ITP: sauerbraten-wake6 -- Free game content for the Sauerbraten game

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: sauerbraten-wake6 (for main)
  Version : 1.0
  Upstream Author: wakeup <[EMAIL PROTECTED]>
* URL : http://www.quadropolis.us/node/1026

http://wakeup.rundumbonn.de/wscm/mapping/wake6.html

* License : Public Domain
  Description : Small but dodgy deathmatch/instagib map for the 
game Sauerbraten
 This is a free map for the 3d game Sauerbraten. Due to the basic 
textures

it looks like cellshading which is pretty amazing.

Find more screenshots of the game at:
http://krum.ethz.ch/sauerbraten/

--
while(!asleep()) sheep++;


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

Bug#457565: Should slocate be still shipped in Debian?

[Andreas Metzler]

Package: slocate
Version: 3.1-1.1

Hello,

I have been pondering to NMU slocate to fix #451792 and #452892,
however I quickly realized that I failed failed to see the point to
invest any time there. Afaik with mlocate we have replacement which

- has got the same feature set
- is faster
- is not dead upstream

So, is there a reason to not simply remove slocate from sid/lenny that
I am simply no aware of? (mlocate could temporarily ship a slocate
dummy package to ease etch-->lenny upgrades.)

Please send followups to both bug-report and d-d. (no need to cc me.)

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Miros/law Baran]

23.12.2007 pisze Kalle Kivimaa ([EMAIL PROTECTED]):

> Turbo Fredriksson <[EMAIL PROTECTED]> writes:
> > Why was it removed from Debian GNU/Linux in the first place!?

> It's never been in Debian. The source package is in non-free, as the
> license didn't permit binary distribution. See e.g.
> http://packages.debian.org/etch/qmail-src for some explanation.

Ah, but it's been there, once. I remember that my first Debian
installation included in the default setup all the accounts used by
qmail (if not the qmail itself).

Jubal (...am I using Debian that long?)

-- 
[ Miroslaw L Baran | jabber id: baran-at-hell-pl | key-id: FC494FC4 | 0101010 ]

 If you can't learn to do it well, learn to enjoy doing it badly.
 -- Ashleigh Brilliant


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

Re: testing build errors on arm/sid

[Norbert Preining]

On Fr, 21 Dez 2007, Julien Cristau wrote:
> $ dchroot sid

Thanks ...

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
WILLIMANTIC (adj.)
Of a person whose hearth is in the wrong place (i.e. between their
legs).
--- Douglas Adams, The Meaning of Liff


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Kalle Kivimaa]

Miros/law Baran <[EMAIL PROTECTED]> writes:
> Ah, but it's been there, once. I remember that my first Debian
> installation included in the default setup all the accounts used by
> qmail (if not the qmail itself).

OK, that's possible, I can only remember back to about 2000, when
there was only the source package. If it has been included as a
binary, then it must have been removed as distributing a binary used
to be illegal until the (recent?) license change.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Bug#457384: ITP: netsend -- a speedy filetransfer and network diagnostic program

[Hagen Paul Pfeifer]

* brian m. carlson | 2007-12-23 14:26:34 [+]:

>Also, madvise(2) is apparently BSD, and even if it's not, it can be 
>substituted with posix_madvise(2).  So if splice is the only system call 
>that isn't portable, it should probably be easy to port.

You scratch the surface! It isn't simple madvice() and splice(): it starts with
TCP_INFO and will end will with obscure[tm] sendfile() flags. Anyway: netsend is
optimized especially for Linux. The FreeBSD network stack works quite well, no
doubt, but we focus on Linux. Thats the name of the game.

So you are right: netsend should be limited in arch.


-- 
Hagen Paul Pfeifer <[EMAIL PROTECTED]>  ||  http://jauu.net/
Telephone: +49 174 5455209   ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
Always in motion, the future is. 


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Turbo Fredriksson]

Quoting Kalle Kivimaa <[EMAIL PROTECTED]>:

> Turbo Fredriksson <[EMAIL PROTECTED]> writes:
>> Why was it removed from Debian GNU/Linux in the first place!?
>
> It's never been in Debian. The source package is in non-free, as the
> license didn't permit binary distribution. See e.g.
> http://packages.debian.org/etch/qmail-src for some explanation.

So what changed? Did Bernstein change his licence!? And can't
the qmail-src maintainer just upload a binary package?


I fail to understand this ITP, and all the objections - wether
or not we SHOULD is not the point as I see it. It's a matter 
of CAN we.. ?


And wether or not Qmail is any good - MY opinion is that it kicks
ANY MTA's but! Postfix and Sendmail both suck big time compared to
the simplicity and speed of Qmail. Opinions are like a butt -
everyone got one (sorry, couldn't remember the English equivalence
of this old Swedish saying - but I asume that the point isn't lost :).


So to be or not to be is irrelevant - the question is: are we
ALLOWED to distribute it or not?


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Kalle Kivimaa]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:
> So what changed? Did Bernstein change his licence!? And can't
> the qmail-src maintainer just upload a binary package?

Yes, the license has been changed, QMail is now fully distributable
and modifiable. Dunno if this ITP should actually be considered an ITH
on qmail-src.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Toni Mueller]

Hi,

On Fri, 21.12.2007 at 11:14:01 -0800, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Is the version that is proposed to be packaged patched to reject mail at
> the SMTP level for unknown users rather than accept mail and bounce it
> later?  qmail in its default operational mode is a spam reflector and
> hence broken by design, and shouldn't be accepted into Debian.  However,
> perhaps this has been fixed by the community since djb's last release?

I suggest packaging qmail-ldap (www.qmail-ldap.org) instead, which
fixes this problem and adds a number of other desirable features as
well (compressed mail transfer, TLS support, cluster support,
you-name-it).


Best,
--Toni++


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Leo "costela" Antunes]

Turbo Fredriksson wrote:

> So what changed? Did Bernstein change his licence!? 

According to[0], yes.

> And can't
> the qmail-src maintainer just upload a binary package?

I suppose so, yes.

> Opinions are like a butt -
> everyone got one (sorry, couldn't remember the English equivalence
> of this old Swedish saying - but I asume that the point isn't lost :).

We got the same saying in Portuguese, but I never thought it made much
sense! :-)
The English version is "Opinions are like assholes: everyone has them
and they usually stink"[1]. Never really heard any native English
speaker use it, though.


Cheers

[0] http://cr.yp.to/qmail/dist.html
[1] http://en.wikiquote.org/wiki/English_proverbs#O

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Which spell checkers to include by default?

[Agustin Martin]

On Sun, Dec 23, 2007 at 02:05:41PM +0100, Bernhard R. Link wrote:
> * Petter Reinholdtsen <[EMAIL PROTECTED]> [071222 20:22]:
> > > Note that the w* packages provide word lists, which are important to
> > > many programs.  One could argue that a standard Unix system should
> > > have a word list; at least, every Unix system I have used provides
> > > one.
> > 
> > OK.  Which programs?  I was only aware of ispell.
> 
> I thought ispell would only use the i* packages and not the w* packages.

ispell has a lookup command that allows you to look in a plain wordlist
for words matching a regexp while you are spell-checking. Both can be in
a different language. It is something like look, but allowing regexps.

> To enhance the list of packages needing w* packages, the cracklib
> packages (like libpam-cracklib) also use it to make sure you are not
> using a known word as password.

Adding look to the lists of commands that can use a wordlist.

-- 
Agustin


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Andrew M.A. Cater]

On Sun, Dec 23, 2007 at 06:54:32PM +0100, Turbo Fredriksson wrote:
> Quoting Kalle Kivimaa <[EMAIL PROTECTED]>:
> 
> > Turbo Fredriksson <[EMAIL PROTECTED]> writes:
> >> Why was it removed from Debian GNU/Linux in the first place!?
> >
> > It's never been in Debian. The source package is in non-free, as the
> > license didn't permit binary distribution. See e.g.
> > http://packages.debian.org/etch/qmail-src for some explanation.
> 
> So what changed? Did Bernstein change his licence!? And can't
> the qmail-src maintainer just upload a binary package?
> 

Qmail is now "in the public domain" as far as I understand it. No other 
licence - which may be problematic, except that djb's text says

"I hereby place the qmail package (in particular qmail-1.03.tar.gz 
with MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) into the public 
domain. You are free to modify the package, distribute modified versions 
etc. " and then a paragraph stating that modifications are not 
encouraged and that identical interfaces should be maintained. 
[See, for more details, http://cr.yp.to/qmail/dist.html effective 30 
November 2007].

> 
> I fail to understand this ITP, and all the objections - wether
> or not we SHOULD is not the point as I see it. It's a matter 
> of CAN we.. ?
> 

We _can_ but the FSF aren't sure about the fact that modification is 
discouraged as I read it.

"The license of Qmail is not a free software license because it mostly 
prohibits the distribution of modified versions"

[Page last modified 2007-12-11 - not sure if that's an ISO or a US date 
so not sure whether that takes into account the licence changes - 
taken from http://www.fsf.org/licensing/licenses/licenses.html ]

See also the Wikipedia article on License-free software though Russell 
Nelson and the OSI now regard it as OSI-free. 

> And wether or not Qmail is any good - MY opinion is that it kicks
> ANY MTA's but! Postfix and Sendmail both suck big time compared to
> the simplicity and speed of Qmail. Opinions are like a butt -
> everyone got one (sorry, couldn't remember the English equivalence
> of this old Swedish saying - but I asume that the point isn't lost :).
> 

Point taken.

> 
> So to be or not to be is irrelevant - the question is: are we
> ALLOWED to distribute it or not?
> 
Possibly, with caveats.

Just my 0.02 Euro c

Andy



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

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Stefano Zacchiroli]

tags 457353 + wontfix
thanks

On Fri, Dec 21, 2007 at 07:20:57PM +, brian m. carlson wrote:
> You're missing a .diff.gz, which means that this is a native package.  This 
> package is in no way specific to Debian, which means that this shouldn't be 
> a Debian-native package.

Sorry, but I disagree with this interpretation. For me a Debian native
package is a package which contains the official debian packaging stuff
in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
software has been used historically always as a Debian package, to me
that is a native Debian package.

There are other examples of packages in the archive which are no way
Debian specific, but which are native as gdome2-xslt is; a fresh example
I have in mind is ikiwiki.

Of course if the global consensus will change so that native packages
are only those Debian-specific I would be more than happy to change
gdome2-xslt, but at the moment I feel there is no such a consensus.

Cc-ing -devel for the sake of this discussion.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Which spell checkers to include by default? (Was: priorities)

[Agustin Martin]

On Sat, Dec 22, 2007 at 08:08:42AM +0100, Petter Reinholdtsen wrote:
> 
> [Anthony Towns]
> > Kind of reviving an old thread, but anyway:
> > It also includes, but afaics, probably doesn't need to (anymore):
> > 
> > ispell, dictionaries-common, iamerican, ibritish, wamerican
> 
> [Agustin Martin]
> > #416572: ibritish: Should not have priority standard 
> 
> We now have aspell, myspell and hunspell as alternatives to ispell,
> and it can be argued that all of them are better than ispell at
> providing spell checking and recommendations for replacements.
> Because of this, I believe it would be a good idea to drop ispell from
> the list of standard packages, and the related packages too (i*, w*).

What I meant in the rest of my mail was that ispell should already be out
of the standard packages (as well as iamerican, ibritish and wbritish),
and the same for any other spellchecker like aspell or hunspell.

Only wamerican was intended to be part of standard. dictionaries-common is
also part of standard because wamerican needs it for wordlists integration
into Debian. This is something I would like to improve, but I am still
unclear about how.

-- 
Agustin


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

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Neil Williams]

Stefano Zacchiroli wrote:
> tags 457353 + wontfix
> thanks
> 
> On Fri, Dec 21, 2007 at 07:20:57PM +, brian m. carlson wrote:
>> You're missing a .diff.gz, which means that this is a native package.  This 
>> package is in no way specific to Debian, which means that this shouldn't be 
>> a Debian-native package.
> 
> Sorry, but I disagree with this interpretation. For me a Debian native
> package is a package which contains the official debian packaging stuff
> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
> software has been used historically always as a Debian package, to me
> that is a native Debian package.

To me, just because a package is only currently used in Debian does not
mean it should be Debian native. Native, to me at least, means "This
package is only likely to *work* on Debian because it needs basic parts
of Debian infrastructure that only Debian (or Debian derivatives) will
be able to provide)." Things like apt and dpkg, basically.

I have a mixture of upstream projects, some of which have only ever been
released in Debian but not all of those are native to Debian. The ones
that are include deb-gview (reads .deb packages), apt-cross, dpkg-cross
and emdebian-tools which are definitely Debian native as they do fancy
things with the apt cache and dpkg build process. Others like pilot-qof,
qof and gpe-expenses are most definitely not native - even though only
Debian/Ubuntu has included pilot-qof in a release AFAICT.

i.e. native should be a last resort - used only when it is all but
impossible for the package to be used outside Debian or some distro
fundamentally based on Debian like Ubuntu.

> Of course if the global consensus will change so that native packages
> are only those Debian-specific I would be more than happy to change
> gdome2-xslt, but at the moment I feel there is no such a consensus.
> 
> Cc-ing -devel for the sake of this discussion.

Gnome is certainly not Debian-specific and there doesn't appear to be
anything in GDome that would appear to make it impossible to use on
Fedora or Gentoo etc.

If this was my package, I'd be tempted to put the source on SF or
somewhere, exclude the debian/ contents from the make dist target but
keep them in whichever RCS you want to use and package it from there.
Then if anyone from Fedora or wherever wants to use it, they can.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Luk Claes]

Neil Williams wrote:
> Stefano Zacchiroli wrote:
>> tags 457353 + wontfix
>> thanks
>>
>> On Fri, Dec 21, 2007 at 07:20:57PM +, brian m. carlson wrote:
>>> You're missing a .diff.gz, which means that this is a native package.  This 
>>> package is in no way specific to Debian, which means that this shouldn't be 
>>> a Debian-native package.
>> Sorry, but I disagree with this interpretation. For me a Debian native
>> package is a package which contains the official debian packaging stuff
>> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
>> software has been used historically always as a Debian package, to me
>> that is a native Debian package.
> 
> To me, just because a package is only currently used in Debian does not
> mean it should be Debian native. Native, to me at least, means "This
> package is only likely to *work* on Debian because it needs basic parts
> of Debian infrastructure that only Debian (or Debian derivatives) will
> be able to provide)." Things like apt and dpkg, basically.
> 
> I have a mixture of upstream projects, some of which have only ever been
> released in Debian but not all of those are native to Debian. The ones
> that are include deb-gview (reads .deb packages), apt-cross, dpkg-cross
> and emdebian-tools which are definitely Debian native as they do fancy
> things with the apt cache and dpkg build process. Others like pilot-qof,
> qof and gpe-expenses are most definitely not native - even though only
> Debian/Ubuntu has included pilot-qof in a release AFAICT.
> 
> i.e. native should be a last resort - used only when it is all but
> impossible for the package to be used outside Debian or some distro
> fundamentally based on Debian like Ubuntu.
> 
>> Of course if the global consensus will change so that native packages
>> are only those Debian-specific I would be more than happy to change
>> gdome2-xslt, but at the moment I feel there is no such a consensus.

I thought this consensus was already a fact and that some maintainers
just disagree and nobody forced them to change yet...

The reasons why it shouldn't be a native package IMHO:
* it's not specific to Debian
* it wastes bandwidth as every upload contains all the sources
* it's confusing for newcomers
* it's error prone for NMUs and security updates

Cheers

Luk


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

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Leo "costela" Antunes]

Luk Claes wrote:
>> Stefano Zacchiroli wrote:
>>> Sorry, but I disagree with this interpretation. For me a Debian native
>>> package is a package which contains the official debian packaging stuff
>>> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
>>> software has been used historically always as a Debian package, to me
>>> that is a native Debian package.

I couldn't find any better and more direct references, but according to
[0] and [1] your interpretation is wrong.


> I thought this consensus was already a fact and that some maintainers
> just disagree and nobody forced them to change yet...

Indeed, I think this should be more directly stated at least on dev-ref.
Policy only contains an oblique reference[0] to this.

> The reasons why it shouldn't be a native package IMHO:
> * it's not specific to Debian
> * it wastes bandwidth as every upload contains all the sources
> * it's confusing for newcomers
> * it's error prone for NMUs and security updates

Agreed.
Additionally it complicates maintainer migration, but your second point
is perhaps the most important.

Cheers

[0] http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
[1] http://www.debian.org/doc/maint-guide/ch-update.en.html#s-orig-tar

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Neil Williams]

Luk Claes wrote:
> Neil Williams wrote:
>> i.e. native should be a last resort - used only when it is all but
>> impossible for the package to be used outside Debian or some distro
>> fundamentally based on Debian like Ubuntu.
>>
> I thought this consensus was already a fact and that some maintainers
> just disagree and nobody forced them to change yet...
> 
> The reasons why it shouldn't be a native package IMHO:
> * it's not specific to Debian
> * it wastes bandwidth as every upload contains all the sources
> * it's confusing for newcomers
> * it's error prone for NMUs and security updates

I'd just add:
* it isn't in the spirit of free software to make it hard for others to
use the code - making a package Debian-native when it could work on any
GNU/Linux or POSIX platform makes it unnecessarily hard for a Fedora or
Gentoo user etc. to package the code and maintain it in their own
distro. How are they to know whether the latest native version is Debian
specific or contains useful "upstream" improvements?

There is plenty of free hosting that could be used for this code - SF is
probably the most common, berlios another.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Turbo Fredriksson]

Quoting Toni Mueller <[EMAIL PROTECTED]>:

> I suggest packaging qmail-ldap (www.qmail-ldap.org) instead, which
> fixes this problem and adds a number of other desirable features as
> well (compressed mail transfer, TLS support, cluster support,
> you-name-it).

I sent a patch to qmail-src to build both 'qmail' AND 'qmail-ldap' packages.
This patch SHOULD be in the BTS. If not, I'm happy to remake it (my source
package build both these binary packages so...).

There are times where qmail-ldap is to much (on hosts where a smart host
is used for example) and there I use the 'simple' qmail package. On mail
servers, I use the qmail-ldap package...


In other words, better integrate the LDAP stuff into the qmail-src (or
simply - if the new license is ok - the 'qmail' source package).

It will be easier to maintain one source package instead of two...

Preferably, the package should be taken over (if the current maintainer
isn't interessted!!) by someone that understand both qmail and qmail-ldap.
I'll be happy to help, but I don't have time to be the official maintainer -
unless I get help that is.


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Toni Mueller]

Hi,

On Sun, 23.12.2007 at 20:17:16 +0100, Turbo Fredriksson <[EMAIL PROTECTED]> 
wrote:
> There are times where qmail-ldap is to much (on hosts where a smart host
> is used for example) and there I use the 'simple' qmail package. On mail
> servers, I use the qmail-ldap package...

why, just set control/ldapsoftok, and you're all set (probably), except
that you need the ldap libs being installed.

> It will be easier to maintain one source package instead of two...

Right. How about integrating ldap-control, too?

> Preferably, the package should be taken over (if the current maintainer
> isn't interessted!!) by someone that understand both qmail and qmail-ldap.
> I'll be happy to help, but I don't have time to be the official maintainer -
> unless I get help that is.

Same thing here. ;)


Best,
--Toni++


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

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Roberto C . Sánchez]

On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote:
> 
> Sorry, but I disagree with this interpretation. For me a Debian native
> package is a package which contains the official debian packaging stuff
> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
> software has been used historically always as a Debian package, to me
> that is a native Debian package.
> 
Well, I am involved in upstream development of a couple of pacakges
which I also maintain for Debian.  Since I keep the debian/ directory in
the upstream VCS, does that make them native?  What about the upstream
where I am not involved in upsteam development, but which for every
Debian package release incorporates the official Debian packaging stuff
upsteam?  Is that package native?

One of the packages in whose upstream maintenance I participate has a
-doc package with a ~5MB .orig.tar.gz.  Are you suggesting that because
I keep the debian/ directory in the same VCS as upstream development
that I need to make a ~5MB upload everytime I make an upload to fix
something trivial?

I am not trying to be pedantic or sarcastic.  I really want to know
since if that is the case, then I am not maintaining my packages
properly.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Neil Williams]

Roberto C. Sánchez wrote:
> On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote:
>> Sorry, but I disagree with this interpretation. For me a Debian native
>> package is a package which contains the official debian packaging stuff
>> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
>> software has been used historically always as a Debian package, to me
>> that is a native Debian package.
>>
> Well, I am involved in upstream development of a couple of pacakges
> which I also maintain for Debian.  Since I keep the debian/ directory in
> the upstream VCS, does that make them native? 

No. I do the same for all my upstream and native packages. Keep the
debian/ files out of the 'make dist' target (or the released tarball if
you don't use autotools) if the code works on most GNU/Linux or POSIX
environments. Lump them in *only* if the code cannot function without
Debian or a Debian derivative. Simple really.

The basic question is: Can the code work on Gentoo, Slackware, Fedora or
something else along those lines. If that is even possible - even if it
may need a patch or two or is completely untested and theoretical, the
package is *not* native, no matter how it may be packaged. You don't
have to get it working on those platforms, just from the basic structure
of the package and it's dependencies decide if there is a fundamental
reason why it could not possibly work outside Debian.

> What about the upstream
> where I am not involved in upsteam development, but which for every
> Debian package release incorporates the official Debian packaging stuff
> upsteam?  Is that package native?

Not necessarily although it probably isn't worth releasing debian/ files
in a general purpose release. It is just a waste.

> I am not trying to be pedantic or sarcastic.  I really want to know
> since if that is the case, then I am not maintaining my packages
> properly.

I think you're doing just fine with the above. It would appear that most
DD's think the same and the New Maintainer Guide certainly confirms that
the mere presence of debian/ files in RCS is no indicator of whether a
package is native or not.

Native is about package functionality and dependencies, not the location
of files - the problem is that the location of files (in .tar.gz not
.diff.gz) can make a non-native package appear native. Doesn't change
the nature of the package itself - general purpose packages that do not
have a .diff.gz are buggy, IMHO.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[brian m. carlson]

[N.B.  I am subscribed to -devel; please do not CC me if you are 
following up there. ]


On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote:

There are other examples of packages in the archive which are no way
Debian specific, but which are native as gdome2-xslt is; a fresh example
I have in mind is ikiwiki.


If ikiwiki FTBFS on GCC 4.3, I will probably file a bug on it, too, when 
I fix the FTBFS.  I don't think ikiwiki should be Debian-native either, 
but I happened to file the bug on gdome2-xslt because I was working on 
it for other reasons.


On the other hand, I would be fine with aptitude being Debian-native 
(although it is not now) because it is specific to Debian.



Of course if the global consensus will change so that native packages
are only those Debian-specific I would be more than happy to change
gdome2-xslt, but at the moment I feel there is no such a consensus.


It is my impression that this is the case already, but Policy is silent 
on the issue; I checked before I filed the bug.  Perhaps if a consensus 
can be reached a guideline should be placed in Policy so that people are 
not further confused.


[0] I have heard rumors that dpkg can also be used on Solaris.
[1] Clearly, I am not hoping or wishing for this in any way, and in 
fact, hope the opposite, but I bring it up for the sake of argument.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Leo "costela" Antunes]

brian m. carlson wrote:

> It is my impression that this is the case already, but Policy is silent
> on the issue; I checked before I filed the bug.  Perhaps if a consensus
> can be reached a guideline should be placed in Policy so that people are
> not further confused.

Please see [0], on this same thread.

Cheers

[0] http://lists.debian.org/debian-devel/2007/12/msg00632.html

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Stephen Gran]

This one time, at band camp, Turbo Fredriksson said:
> So to be or not to be is irrelevant - the question is: are we
> ALLOWED to distribute it or not?

No, actually the question is whether it's worth Debian's time to maintain
it, distribute it, and support it.  qmail is one of the few pieces
of software I've ever seen that is so poorly written that it's author
recommends running it under a supervisor because it can't stay running
on it's own.  It also doesn't support most useful features any reasonable
MTA can be expected to support without fairly extensive patching.

So, right, the argument we're left with is, it's quick and it doesn't
have many apparent security flaws.  The fact that it's a poor netizen
and is also unstable, featureless, and trivially replaced with things
that do respect the FHS are IMHO more important.  If someone actually
cares, I suppose I'll say go ahead, but what a waste of time and energy.
The world has moved on and qmail has been made irrelevant because of
it's original licensing decisions.  I think that at this point, qmail
serves better as an object lesson in license idiocy than as a serious
candidate for the archive.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#457627: ITP: libtest-yaml-valid-perl -- test for valid YAML

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libtest-yaml-valid-perl
  Version : 0.03
  Upstream Author : Jonathan Rockway, 
* URL : http://search.cpan.org/dist/Test-YAML-Valid/
* License : Perl-like (Artistic, GPL)
  Programming Lang: Perl
  Description : test for valid YAML

This module lets you easily test the validity of YAML.

- -- System Information:
Debian Release: unstable/experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

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

iD8DBQFHbvF55qqQFxOSsXQRAp7AAJ4xFke+loMyKGIGr95oZEm778VhIgCfZ//b
NEJdvgdxCWwLxsew+uTs7ys=
=rbIR
-END PGP SIGNATURE-



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

Bug#457630: ITP: libtest-yaml-meta-perl -- test module to validate a META.yml file

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libtest-yaml-meta-perl
  Version : 0.06
  Upstream Author : Barbie <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Test-YAML-Meta/
* License : Perl-like (Artistic, GPL)
  Programming Lang: Perl
  Description : test module to validate a META.yml file

This module was written to ensure that a META.yml file, provided with a
standard distribution uploaded to CPAN, meets the specifications that slowly
being introduced to module uploads, via the use of ExtUtils::MakeMaker,
Module::Build and Module::Install.

- -- System Information:
Debian Release: unstable/experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

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

iD8DBQFHbvQK5qqQFxOSsXQRAvt/AJ0R/yHb5K2bQzDO7HBzTi8B7b4LZACeNd+p
rPURidAdYn/qP+T060kQmxI=
=DPw8
-END PGP SIGNATURE-



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

Re: Bug#457424: ITP: yougrabber -- download simultaneously several videos from youtube.com

[Chris Bannister]

On Sat, Dec 22, 2007 at 12:04:06PM +0100, root wrote:
  
Humourous or risqué?

-- 
Chris.
==

Severity wars are not acceptable

[Don Armstrong]

It appears that I need to underline again who is reponsible for
setting the severity of bugs (and indeed, any control@ modifiable
value.)

If you are not the maintainer, nor a release manager, you do not have
the authority to override the severity that a maintainer has assigned
a bug. If you are fighting with the maintainer's jugement by use of
control, you are *always* in the wrong. Continuing to do so will
result in [EMAIL PROTECTED] restricting your use of control.

If you believe the maintainer has chosen the wrong severity, you have
one remedy: convince a release manager (or tech ctte) that the proper
severity is (or is not) RC. The release manager (or tech ctte) can
then set the severity to a severity which is (or is not) RC. [The
maintainer can still adjust the absolutely severity after such a
point, so long as it remains RC (or not RC).]

At the point at which you and the maintainer disagree, you will note
that none of the further steps involve you altering the severity of a
bug.


Don Armstrong

-- 
Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Russ Allbery]

Stephen Gran <[EMAIL PROTECTED]> writes:

> No, actually the question is whether it's worth Debian's time to maintain
> it, distribute it, and support it.  qmail is one of the few pieces
> of software I've ever seen that is so poorly written that it's author
> recommends running it under a supervisor because it can't stay running
> on it's own.

I'm not a fan of qmail either, but but this just isn't true.  djb
advocates running *everything* under a supervisor process to eliminate
what he sees as one possible type of failure, not because of any specific
problems with qmail.  I've run qmail for years and I've never seen the
supervisor process have to do anything.  It runs as reliably as a daemon
as any other MTA.

I'm switching away from it everywhere for other reasons, most notably its
horrible behavior with spam reflection, but stability is *not* a problem
for qmail.

> It also doesn't support most useful features any reasonable MTA can be
> expected to support without fairly extensive patching.

This is generally true.

> So, right, the argument we're left with is, it's quick and it doesn't
> have many apparent security flaws.

And it's not particularly quick.  It used to be, but qmail development has
been stalled for years, and since then other MTA systems such as Postfix
have caught up.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

about your music, please read..

[music]

Hi, 

I checked out your music page, and want to invite you to start a free artist 
page at IAC. 

IACmusic.com is an indie allstar site, it recently got mention in Rolling 
Stone, and has been called the most innovative music site on the web.  Cashbox 
Magazine liked the site so much that now all indie content on their charts 
comes directly from IAC. Anyway I think your tunes would do well there. Our 
listener base is huge, with a very active community, and we are now in the 
process of purchasing our own mid-market FM station so IAC is about to become a 
launching pad for real radio airplay. 

We are about the music and indie culture.  No cookie-cutters were used in the 
making of this site. Meanwhile, you can sell your downloads with no upfront 
cost and you get 100% of the profits, unlike on Snocap which takes 39 cents out 
of every sale!  Check out the site here, if you want to find real listeners, 
this is the place to do it. 

Here's a direct shortcut to start a free page. Any additional exposure can help 
you get your music to the world. 

Hope to hear your songs at IAC soon.. 

Toby, a&r - IACmusic.com 
 

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Turbo Fredriksson]

Quoting Stephen Gran <[EMAIL PROTECTED]>:

> qmail is one of the few pieces
> of software I've ever seen that is so poorly written that it's author
> recommends running it under a supervisor because it can't stay running
> on it's own.

I wasn't planning on actually replying to this bag of complete rubbish,
but I just couldn't stay away...


You should really get your facts straigt before feeding the FUD!

Qmail is the most secure MTA out there. It's slick, and quite well
written (a little unorthodox, granted) and designed for security!
And noone have still been able to claim the $5k (think it was 5k
anyway) bounty for a security hole (yes, I know there are claims
that there are at least one hole, but I buy Bernsteins 'excuse'
for not paying - if configured correctly, the hole don't exist).


And the supervisor isn't because it can't stay running on it's own,
it's a extra security measure - IF something goes wrong, it won't
affect mail delivery. The key word here is _if_.


In Swedish, there is an old proverb saying "using both suspenders
and belt". Guess the closest English saying would be "better safe
than sorry"...

> It also doesn't support most useful features any reasonable
> MTA can be expected to support without fairly extensive patching.

Can be argued as well, but I'm not completely dismissing this claim -
Qmail work a lot better with a little patching (I do). But all in all,
I actually agree on Bernstein here to. An MTA shouldn't try to be 'smart'
- all that send receipt on acceptance/delivery, reject at SMTP etc (and
claims that this makes Qmail wide open for spams is rubish - it's only
if/when configured incorrectly that this becomes a problem) shouldn't
be done by an MTA (it isn't in the SMTP RFC that I know of).

> So, right, the argument we're left with is, it's quick and it doesn't
> have many apparent security flaws.

It have NO security flaws (especially not if patching it with the most
obvious patches).

> The fact that it's a poor netizen and is also unstable

Now, come on!! Get a fng reality check! Have you ever even USED
Qmail?! And actually READ it's code!?

I have Postfix crash more often on my home machine (~ 10 mails / 24h -
using an smarthost) than Qmail do on my main mailservers (~ 10k mails / 24h).

> featureless, and trivially replaced with things
> that do respect the FHS are IMHO more important.

Qmail [can] respect[s] the FHS just perfectly! Especially now when it's
public domain (if the modifications is ok that is - then we're back to
my original point - ARE we allowed to distribute modified versions!?).

> If someone actually cares, I suppose I'll say go ahead, but what a
> waste of time and energy.

I rather waste it on something good like Qmail than crap like Postfix
and Sendmail.

Now, THAT'S a complete waste of time and energy! Slow, complicated (to
configure correctly) and way to bulky.

And then I haven't even started on the code itself... It's the biggest
mishmash of cooks I have seen in a long time (for a project this important).

> The world has moved on and qmail has been made irrelevant because of
> it's original licensing decisions.  I think that at this point, qmail
> serves better as an object lesson in license idiocy than as a serious
> candidate for the archive.

Here we actually agree (on the licencing stuff any way). It's easy to
say "if only", but if the licencing is still bad, then it shouldn't go
into Debian GNU/Linux...


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Turbo Fredriksson]

Quoting Toni Mueller <[EMAIL PROTECTED]>:

> Right. How about integrating ldap-control, too?

The patch I'm talking about have this (quite naturally :).


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