Your message dated Fri, 1 Apr 2011 09:34:55 -0700
with message-id <20110401163455.gi23...@teltox.donarmstrong.com>
and subject line Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail
inclusion (or not) in Debian
has caused the Debian Bug report #510415,
regarding tech-ctte:
On Fri, 01, Apr, 2011 at 01:17:52PM +0100, Mark Hymers spoke thus..
> I've just checked the packages, and given the constraints of #510415, I
> have accepted netqmail, dot-forward, fastforward, qmail-run and
> qmail-tools. I will shortly be filing RC bugs against each of these as
&g
Processing commands for cont...@bugs.debian.org:
> clone 620378 -1 -2 -3 -4
Bug#620378: netqmail: Must not enter testing for at least 1 month
Bug 620378 cloned as bugs 620381-620384.
> block 510415 by 620378
Bug #510415 [tech-ctte] tech-ctte: Qmail inclusion (or not) in Debian
Was not bloc
On Tue, 29, Mar, 2011 at 08:14:21AM -0700, Don Armstrong spoke thus..
> What is the current status of this?
I've just checked the packages, and given the constraints of #510415, I
have accepted netqmail, dot-forward, fastforward, qmail-run and
qmail-tools. I will shortly be filing
On Tue, Mar 29, 2011 at 08:15:09AM -0700, Don Armstrong wrote:
> On Tue, 29 Mar 2011, Gerrit Pape wrote:
> > Hi, packages are in NEW since more than one year without any comments
> > from ftpmasters. I don't think that's "standard NEW processing for
> > licensing, copyright, and general packaging
no longer in doubt, and so the CTTE has resolved that
> >
> > 3. Qmail is to be allowed in to the archive after a patch to resolve
> > the delayed bounces issue, where mail sent to an invalid recipient
> > which a reasonable MTA is capable of knowing is invalid is accepted
4 people ranking 3 first, and Steve ranking it second, I believe
> > the outcome is no longer in doubt, and so the CTTE has resolved that
> >
> > 3. Qmail is to be allowed in to the archive after a patch to resolve
> > the delayed bounces issue, where mail sent to an inva
On Thu, Aug 27, 2009 at 02:34:16PM -0700, Don Armstrong wrote:
> On Thu, 27 Aug 2009, Andreas Barth wrote:
> > 34215
>
> With 4 people ranking 3 first, and Steve ranking it second, I believe
> the outcome is no longer in doubt, and so the CTTE has resolved that
>
> 3. Q
- Forwarded message from mailer-dae...@a.mx.smarden.org -
Date: 17 Nov 2010 09:18:34 -
From: mailer-dae...@a.mx.smarden.org
To: pape-qn-f5143...@smarden.org
Subject: failure notice
Hi. This is the qmail-send program at a.mx.smarden.org.
I'm afraid I wasn't able to de
On Mon, May 24, 2010 at 12:40:10PM +, Gerrit Pape wrote:
> On Sun, Mar 14, 2010 at 11:19:11AM +, Archive Administrator wrote:
> > (new) qmail-run_2.0.2.dsc extra mail
> > (new) qmail-run_2.0.2.tar.gz extra mail
> > (new) qmail-run_2.0.2_all.deb extra mail
> > set
On Sun, Mar 14, 2010 at 11:19:11AM +, Archive Administrator wrote:
> (new) qmail-run_2.0.2.dsc extra mail
> (new) qmail-run_2.0.2.tar.gz extra mail
> (new) qmail-run_2.0.2_all.deb extra mail
> sets up qmail as mail-transfer-agent
[...]
Hi, can you please say something about the s
On 11876 March 1977, Russ Allbery wrote:
> If I were you, I'd probably use a debconf question asking whether or not
> to enable /etc/aliases handling, with the default answer being yes, so
> that people who want the native qmail behavior can disable it. I'm sure
> that'
On 11876 March 1977, Gerrit Pape wrote:
> Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
> such a newaliases program
> #!/bin/sh
> cat >&2 < qmail on Debian by default doesn't support the /etc/aliases database,
> but handles mail
Gerrit Pape writes:
> Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
> such a newaliases program
> #!/bin/sh
> cat >&2 <
> qmail on Debian by default doesn't support the /etc/aliases database,
> but handles ma
packages
> > should be adapted, so that the qmail-run package provides the newaliases
> > program.
>
> Actually, with the first set of packages uploaded to ftp-master in April
> 2008, the qmail-run package included a minimal newaliases program (doing
> nothing but output a w
* Aníbal Monsalve Salazar (ani...@debian.org) [090829 12:39]:
> On Sat, Aug 29, 2009 at 11:46:05AM +0200, Kurt Roeckx wrote:
> >[...]
> >I think it's clear that option 3 wins.
>
> Your message wasn't signed.
Where does the constitution require this? It also isn't required at
all that somebody do
On Sat, Aug 29, 2009 at 11:46:05AM +0200, Kurt Roeckx wrote:
>[...]
>I think it's clear that option 3 wins.
Your message wasn't signed.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote:
>
> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing,
nce message contents are not crash-proof.
> > Qmail does not value the contents of a bounce message. Dan documents this
> > in a subordinate clause of his qmail reliability FAQ. That means: if your
> > qmail is bouncing mail and at the same time, your system crashes, the
> >
On Thu, 2009-08-20 at 21:00 -0700, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, a
* Steve Langasek:
> On Tue, Feb 03, 2009 at 08:32:20AM +, Gerrit Pape wrote:
>> 2.1 I'd suggest not to change that, it's a good compromise between
>> performance and reliability.
>
> 2.1. Bounce message contents are not crash-proof.
>
> Qmail do
Your message dated Thu, 27 Aug 2009 14:34:16 -0700
with message-id <20090827213416.gd13...@volo.donarmstrong.com>
and subject line Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail
inclusion (or not) in Debian
has caused the Debian Bug report #510415,
regarding tech-ctte:
* Don Armstrong (d...@debian.org) [090821 20:46]:
>
> I'm calling for a vote on the following options[1]:
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and gene
Steve Langasek writes:
> On Wed, Aug 26, 2009 at 09:18:03PM -0700, Russ Allbery wrote:
>> Well, that's a specification for multipart/report, which qmail doesn't
>> attempt to comply with. (Neither do many other MTAs, although more do
>> now than used to.)
>&
On Wed, Aug 26, 2009 at 09:18:03PM -0700, Russ Allbery wrote:
> Well, that's a specification for multipart/report, which qmail doesn't
> attempt to comply with. (Neither do many other MTAs, although more do now
> than used to.)
> At a basic SMTP protocol level, a lot of
ULD return only the headers.
Well, that's a specification for multipart/report, which qmail doesn't
attempt to comply with. (Neither do many other MTAs, although more do now
than used to.)
At a basic SMTP protocol level, a lot of mail servers no longer return
bounces at *all*, or at le
On Sun, Aug 23, 2009 at 06:06:53PM -0400, Sam Hartman wrote:
> >>>>> "Steve" == Steve Langasek writes:
> Steve> Qmail does not value the contents of a bounce
> Steve> message. Dan documents this in a subordinate clause of his
> Steve&
. which apparently wasn't the case.
Well, given the outcome of the DebConf TC BoF, where Ian said he would
follow up regarding the other bug he's encountered which didn't make the
referenced list of qmail bugs, I expected that we would wait for that
information to come in before mo
>>>>> "Sam" == Sam Hartman writes:
>>>>> "Steve" == Steve Langasek writes:
Steve> Qmail does not value the contents of a bounce message. Dan
Steve> documents this in a subordinate clause of his qmail
Steve> reliability FAQ
>>>>> "Steve" == Steve Langasek writes:
Steve> Qmail does not value the contents of a bounce
Steve> message. Dan documents this in a subordinate clause of his
Steve> qmail reliability FAQ. That means: if your qmail is
Steve> bouncing m
On Sun, Aug 23, 2009 at 02:22:32AM -0700, Steve Langasek wrote:
> Certainly, I see a number of issues on
> <http://home.pages.de/~mandree/qmail-bugs.html> that I would not like to see
> in any package in the archive, not just the delayed-reject bug, and I would
> like to know fr
I'm of the personal opinion that having the package in unstable and
enumerating the set of bugs using the BTS is (in general) the best way
to do just this, though the delayed bounce issue is serious enough to
delay the package. There are certainly serious bugs, but in my
opinion, they're not b
On Sun, Aug 23, 2009 at 02:32:36AM -0700, Steve Langasek wrote:
> On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> > ignorance of rfc 3464
>
> This is one that I would like to see more discussion about; I've definitely
> found qmail's non-standard DSNs irksome, looking like convers
* Steve Langasek (vor...@debian.org) [090823 11:32]:
> On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> > b. There are lots of issues why qmail doesn't look too competitive,
> > like the static user ids,
>
> I don't see any other mention of static us
On Sat, Jan 10, 2009 at 06:46:31AM -0800, Russ Allbery wrote:
> > We have experimental, though there is nothing in effect that prevents a
> > maintainer to upload experimental packages to unstable atm...
> Packages only in experimental are ignored by Release and Security, so that
> would address p
On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> b. There are lots of issues why qmail doesn't look too competitive,
> like the static user ids,
I don't see any other mention of static user ids in this discussion. Can
you explain what the problem is there? Are
On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyr
On Thu, Aug 20 2009, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packag
On Thu, 20 Aug 2009, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packag
Don Armstrong writes:
> I'm calling for a vote on the following options[1]:
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
I'm calling for a vote on the following options[1]:
| 1. Qmail is to be allowed into the archive without special
| preconditions. Ftpmaster should perform standard NEW processing for
| licensing, copyright, and general packaging issues as normal.
|
| Qmail is subject to the normal re
On Fri, 14 Aug 2009, Andreas Barth wrote:
> I think it would be good to get rid of at least the "does delayed
> bounces" before upload.
Ok.
> For all the other issues, RC bugs are an option.
Right.
> I also think that even in case we decide to allow qmail in that
> sti
he archive. [It's perfectly reasonable to have a moving
> > set of things to fix for propogation to testing, though.]
>
> I agree with Don on this, for the record.
I think it would be good to get rid of at least the "does delayed
bounces" before upload. For all the other i
Don Armstrong writes:
> Would it be enough for these issues to be filed as RC bugs and the
> package be allowed into unstable, or is there a set of issues that
> need to be fixed before this happens? [If there is a set, what is it?]
> I'm fine with specifically spelling out the issues that we're
On Wed, 12 Aug 2009, Andreas Barth wrote:
> * Don Armstrong (d...@debian.org) [090811 23:04]:
> > 1. Qmail is to be allowed into the archive without special
> > preconditions. Ftpmaster should perform standard NEW processing for
> > licensing, copyright, and general packa
* Don Armstrong (d...@debian.org) [090811 23:04]:
> 1. Qmail is to be allowed into the archive without special
> preconditions. Ftpmaster should perform standard NEW processing for
> licensing, copyright, and general packaging issues as normal.
As of now, qmail should definitly not b
On Fri, 07 Aug 2009, Don Armstrong wrote:
> On Sat, 25 Jul 2009, Andreas Barth wrote:
> > So, I can see three different ways to continue. In any case a. and c.
> > should be fixed if the package is allowed into Debian.
> >
> > 1. Allow qmail to go into Debian (inc
On Sat, 25 Jul 2009, Andreas Barth wrote:
> So, I can see three different ways to continue. In any case a. and c.
> should be fixed if the package is allowed into Debian.
>
> 1. Allow qmail to go into Debian (including squeeze).
>
> 2. Allow qmail into Debian unstable, but pr
* Russ Allbery (r...@debian.org) [090726 00:50]:
> I do think that accept and bounce these days is a show-stopper, but with
> that fixed, I have a hard time seeing the other issues as show-stoppers.
> I do think that the newaliases integration should be fixed so that Policy
> aliases handling works
Andreas Barth writes:
> So, I can see three different ways to continue. In any case a. and c.
> should be fixed if the package is allowed into Debian.
>
> 1. Allow qmail to go into Debian (including squeeze).
>
> 2. Allow qmail into Debian unstable, but prevent it (at lea
Hi,
trying to summarize the discussion, there are a few technical issues:
a. By far most important is the topic of delayed bounces. Gerit
offered to change the default to not produce them.
b. There are lots of issues why qmail doesn't look too competitive,
like the static user ids, igno
Peter Madams writes:
> Gerrit Page has been trying to add a qmail package, for a long time!
> http://smarden.org/pape/Debian/sid.html
>
> What's the problem?
http://bugs.debian.org/510415 documents the problems at some length. I
don't think everyone agrees about th
Hi,
Gerrit Page has been trying to add a qmail package, for a long time!
http://smarden.org/pape/Debian/sid.html
What's the problem?
I have been using qmail with Debian for years, it is the only MTA
to offer me the security, performance and flexibility that I need.
I want to add my na
orward package is sufficient, while preserving flexibility. I now
> see that on systems where exim is installed as default MTA, installing
> the fastforward package will result in a file conflict. The packages
> should be adapted, so that the qmail-run package provides the newalias
a representative one, but handling big
installations is one of the goals too.
| All that being said, I don't consider this single issue sufficiently
| severe to argue against including qmail in the archive. I find it very
| annoying, but it falls short of being actively broken IMO. A few m
s single issue sufficiently
severe to argue against including qmail in the archive. I find it very
annoying, but it falls short of being actively broken IMO. A few more
qmail sites in the world realistically isn't going to make that big of a
difference to the problem of unparseable bounce
* Russ Allbery [Wed, 04 Feb 2009 14:02:21 -0800]:
> > This is trivial to work around -- use VERP and you never have to parse a
> > bounce again.
> It's a great workaround for small lists and not so great for large
> lists with lots of recipients at the same destination server.
AFAIK the Debian l
Tollef Fog Heen writes:
> | This is a more serious problem. Mailman, for example, can't handle qmail
> | bounce messages very well. I don't think it, by itself, would be
> | sufficiently severe to keep it out of the archive, but it's troubling in
> | combination
]] Russ Allbery
| > - Mailing list software fails to parse the error message
|
| This is a more serious problem. Mailman, for example, can't handle qmail
| bounce messages very well. I don't think it, by itself, would be
| sufficiently severe to keep it out of the archive, but i
On Tue, Jan 06, 2009 at 12:38:11AM +, Ian Jackson wrote:
> Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
> Debian"):
> > Criteria that speak against inclusion:
> > - no real upstream
> What is required is that _someone_ is able an
On Mon, 12 Jan 2009, Steve Langasek wrote:
> > Whoever takes the decision, we still need an agreed upon definition of
> > crap, otherwise people will be unhappy to not be able to maintain the
> > piece of software they care about. Even if that software is crap.
>
> Do the definitions of "grave" an
On Sat, Jan 10, 2009 at 04:35:59PM +0100, Raphael Hertzog wrote:
> > There are three possibilities here:
> > 1) The ftp team have a duty to judge whether a NEW package is too buggy to
> > be
> >allowed into the archive.
> > 2) The ftp team may exclude NEW packages from the archive that they b
Joerg Jaspert writes:
> One more thing (I dont think its mentioned already) I got pointed at:
> http://www.daemonology.net/papers/bsdcan06.pdf
> Page 9 says:
> · Bug discovered in qmail: If you can send a >2GB message to qmailsmtpd,
> you can execute arbitrary code via a
One more thing (I dont think its mentioned already) I got pointed at:
http://www.daemonology.net/papers/bsdcan06.pdf
Page 9 says:
· Bug discovered in qmail: If you can send a >2GB message to qmailsmtpd,
you can execute arbitrary code via an integer overflow.
Response from DJB: &quo
* Kalle Kivimaa:
> Steve Langasek writes:
>> Can you expand here on the consequences of ignoring RFC1894? I'm aware that
>> qmail delivery failure mails look different (and, I might argue,
>> gratuitously so) than those of other mail systems, but does this cause
>&g
Kalle Kivimaa writes:
> Steve Langasek writes:
>> Can you expand here on the consequences of ignoring RFC1894? I'm aware
>> that qmail delivery failure mails look different (and, I might argue,
>> gratuitously so) than those of other mail systems, but does this
Steve Langasek writes:
> Can you expand here on the consequences of ignoring RFC1894? I'm aware that
> qmail delivery failure mails look different (and, I might argue,
> gratuitously so) than those of other mail systems, but does this cause
> interoperability problems for oth
On Sat, Jan 10, 2009 at 10:02:59AM +0100, Raphael Hertzog wrote:
> > > - Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
> > > /usr/sbin. This is at least sick, if not again an FHS
> > > violation. var/lib is for "Variable state information&qu
at's reasonable; I
Of course no. I was just pointing out that if we consider it a duty of the
ftpmasters to judge quality, then the treatment of qmail was unfair
compared to all the other crap that got in without review.
But as I'm not the one arguing that it's a duty, I don'
Luk Claes writes:
> Raphael Hertzog wrote:
>> What are those teams? I can only think of the security team that has a
>> duty to support the security of the stable release. And even this team
>> has now some (widely unknown) way to say that they don't fully support
>> some specific packages (they
rity of the stable release. And even this team has
> now some (widely unknown) way to say that they don't fully support some
> specific packages (they do that with a specific tag in debtag).
There is the QA Team, the Release Teams and the Security Team at least.
> And in the case of
rent consensus is regarding which issues should or shouldn't be blockers.
I agree with everything you said except one point you misunderstood IMO:
> > - Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
> > /usr/sbin. This is at least sick, if not again an FHS
> &g
way to say that they don't fully support some
specific packages (they do that with a specific tag in debtag).
And in the case of Qmail, the security team said that they have no
probleme supporting it.
> If the packages aren't accepted in the first place, fixing the bugginess
> is t
Steve Langasek writes:
> On Fri, Jan 09, 2009 at 09:33:50AM +0100, Raphael Hertzog wrote:
>> We all know how NEW processing regularly result in complaints.
Telling people "no" results in complaints. Unless we're saying that we
shouldn't ever tell people no on accepting packages, I don't think t
On Fri, Jan 09, 2009 at 09:33:50AM +0100, Raphael Hertzog wrote:
> We all know how NEW processing regularly result in complaints. Trying to
> enhance the policy to be more fair could help. IMO the quality issues that
> are not covered by an explicit policy point should result in bugs being
> filed
n Policy - but that's a separate question, and doesn't lead
me to a different conclusion than the one they've reached regarding the
current qmail package.
> In fact, I tend to think that Qmail is special-cased because it's popular
> and the problems are well known.
iour, including the
> backscatter spam issue, failing to use secondary MXs, ignoring
> RFC1894, and unbundling of outgoing messages (yay for traffic/resource
> waste)[2], thus being unsupportably buggy (Policy 2.2.1)
Can you expand here on the consequences of ignoring RFC1894? I'm aware that
*sigh*
sent this from the wrong address.
Bdale> The way I look at this is that it has not been a primary
Bdale> *expectation* of the project that the ftpmasters review and
Bdale> approve the quality of the software that is packaged. The
Bdale> lack of a routine expectation does a
hem broad discretion to do their work.
> So Gerrit should contact the leader or try a GR to be able to package
> qmail? I'm not sure that's the proper way either.
It certainly doesn't seem like a reasonable response given the obvious
alternative of working on the issues identi
gt; Having said that I think it's important to support the ftpmasters'
> discretion so I'm going to carry on and discuss it a bit ...)
>
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
> Debian"):
> > On Tue, 06 Jan 2009, Ia
..)
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> On Tue, 06 Jan 2009, Ian Jackson wrote:
> > I'm not uneasy with this at all. The ftpmasters' job is not to decide
> > the policy and then implement it without discretion.
On Tue, 06 Jan 2009, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
> Debian"):
> > I'm particularly uneasy with letting the ftpmasters decide
> > what's acceptable in the Debian archive on some non-usu
d until the RMs
> > have a chance to come to a determination
> > be an acceptable compromise for the ftpmasters and the prospective
> > Qmail maintainer(s)? (Or at least, a start towards something that
> > could possibly be compromised on?)
> +1.
>
Hi,
as the submitter was whining why only one member of the tech ctte commented so
far, I'll comment as well:
* Ian Jackson (i...@davenant.greenend.org.uk) [090106 02:02]:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
> Debian"):
> > Ge
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> I'm particularly uneasy with letting the ftpmasters decide
> what's acceptable in the Debian archive on some non-usual policy
> requirements that can be difficult to justify.
I&
On Tue, 06 Jan 2009, Kalle Kivimaa wrote:
> Well, I personally am against the Qmail in Debian at it's current
> state because I consider it to have at least one critical security
> bug and several other RC bugs, and I don't see how to solve the
> critical bug without a ser
>> Indeed practically the only reason why people want Qmail is because
>> they believe the hype about how ultra secure it is - which is relevant
>> (if you believe it) in precisely the circumstances where Qmail's
>> problems are most severe.
> When Debian was runnin
On Tue, 06 Jan 2009, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
> Debian"):
> > On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > > Yet, we do see that there are people who want Qmail, and instead of
> > >
Raphael Hertzog writes:
> I'm particularly uneasy with letting the ftpmasters decide
> what's acceptable in the Debian archive on some non-usual policy
> requirements that can be difficult to justify.
Well, I personally am against the Qmail in Debian at it's current
sta
ceptable compromise for the ftpmasters and the prospective
> Qmail maintainer(s)? (Or at least, a start towards something that
> could possibly be compromised on?)
+1.
I find this suggestion to be much more in line with our current
procedures.
I'm particularly uneasy with letting the
On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> Yet, we do see that there are people who want Qmail, and instead of
> maintaining it in an own repository want it in Debian. As it is
> unlikely that the positions of the Qmail supporters and us will
> change soon to let us find a solution th
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > Yet, we do see that there are people who want Qmail, and instead of
> > maintaining it in an own repository want it in Debian. As it
Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> Criteria that speak against inclusion:
> - no real upstream
I don't think that this is necessarily a showstopper. We have many
important packages in Debian that have defunct or completely
d seems like something
worth thinking twice about.
Although maybe I'm wrong that it would be unlikely to be fixed. There are
replacements for qmail-smtpd that do not have this problem --
qmail-qpsmtpd, for example. A qmail package made with one of those
replacements would, to me, be a lot more comp
Raphael Hertzog writes:
> All those are good reasons to not choose the software as a user but not to
> not include them in Debian. We don't know how our users are going to use
> it and there might be use cases where those shortcomings are not
> problematic.
I think the more abstract question here
; It's the first time I hear that the ftpteam has used this requirement to
> reject packages. Have you used it for other packages already?
I think we did, yes.
> Can you point us to the current source packages so that we can have a look
> at them?
merkel:~joerg/qmail
>> basic
urrent Upstream.
It's the first time I hear that the ftpteam has used this requirement to
reject packages. Have you used it for other packages already?
Can you point us to the current source packages so that we can have a look
at them?
> Yet, we do see that there are people who want Qmail
Package: tech-ctte
Severity: normal
Dear Technical committee,
the ftpteam has been thinking about the inclusion of QMail into Debian
for some time already. We feel that qmail, unless heavily patched, is
not a suitable MTA at this time and age. It is plagued by numerous bugs
(or misbehaviours
98 matches
Mail list logo
