Re: qmail and related packages in NEW

[Russ Allbery]

Bjørn Mork <[EMAIL PROTECTED]> writes:
> Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:

>> We've discussed this at the Security Team meeting in Essen and we don't
>> have a problem with qmail being included in Lenny.

> You are aware of upstream's attitude towards security holes?  There are
> lots of assumptions like "nobody will ever do ...".

> E.g, quoting from http://cr.yp.to/qmail/guarantee.html :

djb is no longer upstream for qmail in any useful way.  It's very unlikely
that he'll ever release another version, and in practice the software is
now supported by a different set of people.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: qmail and related packages in NEW

[Bjørn Mork]

Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:

> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.

You are aware of upstream's attitude towards security holes?  There are
lots of assumptions like "nobody will ever do ...".

E.g, quoting from http://cr.yp.to/qmail/guarantee.html :

  In May 2005, Georgi Guninski claimed that some potential 64-bit
  portability problems allowed a ``remote exploit in qmail-smtpd.'' This
  claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd
  process, so there is no problem with qmail's assumption that allocated
  array lengths fit comfortably into 32 bits.


And as we all know, nobody needs more than 640 kB RAM anyway :-)



Bjørn
-- 
If you've seen one Jewish grandmother, you've seen them all, huh?  So,
Mexican people are inherently superior to old people


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

Re: qmail and related packages in NEW

[Florian Weimer]

* Bernd Eckenfels:

> In article <[EMAIL PROTECTED]> you wrote:
>> Personally, I'm more concerned about manual constant propagation in
>> some parts of the code base (like using the integer literal 4 for the
>> size of an IPv4 address), and similar coding style issues.  But this
>> is certainly not restricted to qmail (Bernstein's DNS code suffers
>> from that to a higher degree, and it's in the archive).
>
> Well, do you think the size of ipv4 addresses ever will change? :)

Ask the poor guys who wrote IPv6 patches for djbdns.


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

Re: qmail and related packages in NEW

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Personally, I'm more concerned about manual constant propagation in
> some parts of the code base (like using the integer literal 4 for the
> size of an IPv4 address), and similar coding style issues.  But this
> is certainly not restricted to qmail (Bernstein's DNS code suffers
> from that to a higher degree, and it's in the archive).

Well, do you think the size of ipv4 addresses ever will change? :)

Gruss
Bernd


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

Re: qmail and related packages in NEW

[Florian Weimer]

* Gerrit Pape:

> On Mon, Dec 01, 2008 at 03:33:43PM +0100, Florian Weimer wrote:
>> * Joerg Jaspert:
>> > First - the packaging is nowhere near the standard Debian aspires to in the
>> > archive:
>> >
>> > Qmail is an MTA and as such should follow Debian Policy (for example 
>> > Section
>> > 11.6).  It's therefore not a very good start that an MTA package needs
>> > additional packages (qmail-run) installed to perform the minimal tasks
>> > required of mail-transport-agent, and yet another package (fastforward) to
>> > support /etc/aliases.
>> 
>> Yuck.  I wasn't aware of that.  So the security discussion was kind of
>> a red herring, after all.
>
> Hi, how exactly is that a policy violation?

If the MTA package is qmail-run, it must depend on fastforward, in
order to comply with Policy 11.6 (a Recommends: is not sufficient,
IMHO).  Using a homegrown init system by default seems in conflict
with Policy 9.3, in particular 9.3.2.

> I still think this is a good thing, providing valuable flexibility to
> the users.  What problem do you see?  Is it that the packages are
> modularised, and not a single monolithic qmail package?  Is it the
> name?, should the 'qmail-run' MTA package named 'qmail', and the current
> 'qmail' package 'qmail-core' or so?

I guess qmail-run is fine for a package which does not integrate well
with the standard Debian init system.

However, my comment in response to Jörg's email was mainly intended to
put the security team's response into perspective (given that
arguments based on software security concerns are often used to back
quite different goals).  I did not want to focus on specific rejection
reasons per se.


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

Re: qmail and related packages in NEW

[Gerrit Pape]

On Fri, Nov 28, 2008 at 08:51:01PM +0100, Neil Williams wrote:
> On Fri, 28 Nov 2008 18:12:42 +
> Gerrit Pape <[EMAIL PROTECTED]> wrote:
> > Lacking any response, I can only guess what the reason for the delay
> > is.
> 
> IMHO, the response has been given and your replies have not provided
> sufficient grounds to change the response. Personally, I think that is
> entirely fair.
> 
> > >From my point of view this reason is questionable, and I stated so
> > >in my
> > response to the reject mail.  Receiving no response within eight weeks
> > tells me that discussing doesn't work.
> 
> Discussions only work when new information is available. Rehashing the
> same points in the hope that repetition wins the day is just boring.

Hi, surely new information was made available, see my reply to the
rejection mail
 http://lists.debian.org/debian-wnpp/2008/09/msg00055.html

Additionally to addressing technical issues, I took the advise from
ftpmasters and reconsidered re-uploading the packages.  After two
months, and receiving several mails from users asking about the progress
of the inclusion into Debian main after qmail was placed into the public
domain, I re-read some public mails like
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#35
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#50
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#111
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#121
 http://lists.debian.org/debian-wnpp/2008/03/msg00149.html
 http://lists.debian.org/debian-publicity/2008/07/msg3.html

This made me think there're people interested in having the packages
included, so here we are.

> > On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote:
> > > On Sun, Jul 06, 2008 at 02:19:30PM +, Joerg Jaspert wrote:
> > > > Aside from these technical - and possibly fixable - problems, we
> > > > (as in the ftpteam) have discussed the issue, and we are all of
> > > > the opinion that qmail should die, and not receive support from
> > > > Debian. As such we *STRONGLY* ask you to reconsider uploading
> > > > those packages.
> > > >
> > > > Qmail is dead upstream and requires a whole set of patches to even
> > > > begin to work in the manner expected of a modern MTA.  Given
> > > > this, the fact that this means there is also no upstream security
> > > > support, and the fact that Debian already contains at least three
> > > > reasonable MTAs, we see no need to add qmail to the archive. So -
> > > > please reconsider if it really helps Debian to have those
> > > > packages. Also feel free to start a public discussion on
> > > > debian-devel@lists.debian.org about the issue, including any
> > > > relevant information from this email, in order to gather opinions
> > > > from other project members.
> 
> To me, that sounds like a perfectly reasonable and calm response to
> your original question.
> 
> Packages that are dead upstream are always going to be a headache for
> the security team and the release team. Bit rot is a constant source of
> new bugs as all the packages around the dead one(s) continue to be
> developed and improved.
> 
> > > We all know, I guess, that there's lots of different opinions on the
> > > quality and usability of qmail.  There're people thinking like you,
> > > and other people, including me, that have a different opinion.  I
> > > respect your opinion, please respect ours too.  You're free to not
> > > install/use the packages.  I've been contacted by several people
> > > since I announced my intention to package qmail, speaking in favor
> > > of the inclusion into Debian.

> There are always different opinions. What matters is whether there is
> any new information to bring to the discussion.

>From my experience, starting a discussion about what the ftpmasters
wrote above leads to nowhere, so I refrained from doing so and talked
about opinions.  To me it's clear that upstream isn't dead, I see signs
of him doing development on dnscurve for example.  Also qmail has
security support, not only that, it has a security guarantee.  And it
doesn't need a whole set of patches, I know that, I use my packages
since years.
Finally, the source package is netqmail, which is created by a team of
valuable qmail contributors, maintained and supported by them.  This
information is included in debian/copyright and the README file.

Regards, Gerrit.


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

Re: qmail and related packages in NEW

[Gerrit Pape]

On Mon, Dec 01, 2008 at 03:33:43PM +0100, Florian Weimer wrote:
> * Joerg Jaspert:
> > First - the packaging is nowhere near the standard Debian aspires to in the
> > archive:
> >
> > Qmail is an MTA and as such should follow Debian Policy (for example Section
> > 11.6).  It's therefore not a very good start that an MTA package needs
> > additional packages (qmail-run) installed to perform the minimal tasks
> > required of mail-transport-agent, and yet another package (fastforward) to
> > support /etc/aliases.
> 
> Yuck.  I wasn't aware of that.  So the security discussion was kind of
> a red herring, after all.

Hi, how exactly is that a policy violation?

Please see the answer to that paragraph in my reply (including full
quote) to the rejection mail
 http://lists.debian.org/debian-wnpp/2008/09/msg00055.html

On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote:
> Hmm, the MTA package actually is qmail-run, as can be read from the
> README.Debian's in the qmail-run and qmail packages.  And qmail-run
> needs the qmail package, which provides the qmail programs and queue
> structure, as well as the fastforward package, which provides support
> for the /etc/aliases database.  I can't see anything wrong with this, to
> the contrary, the modularity of the packages provides more flexibility,
> e.g.:
>
>  o users can install the qmail package without the qmail-run package to
>configure qmail as MTA manually, next to another MTA package already
>installed on the system
>  o users can install the qmail package without the qmail-run package if
>they wish to use some programs from the qmail package, e.g.
>qmail-popup and qmail-pop3d, and wish to have a different default
>MTA installed, such as postfix
>  o users can disable the /etc/aliases support, and switch to a different
>alias handling if they like; the package providing the /etc/aliases
>database support can then be removed from the system

I still think this is a good thing, providing valuable flexibility to
the users.  What problem do you see?  Is it that the packages are
modularised, and not a single monolithic qmail package?  Is it the
name?, should the 'qmail-run' MTA package named 'qmail', and the current
'qmail' package 'qmail-core' or so?

BTW, I maintain several packages in the Debian archive already that do
just the same, a package containing the programs, and a separate package
that provides the service.  So I can happily run bincimap next to
dovecot, and twoftpd next to some other ftp server, on the same machine.

Users repeatedly request such thing, e.g.
 http://lists.debian.org/debian-devel/2005/08/msg01308.html

I know about that opinion
 http://lists.debian.org/debian-devel/2005/08/msg01329.html
but actually nothing came up within three years
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500176

Regards, Gerrit.


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

Re: qmail and related packages in NEW

[Luk Claes]

David Kaufman wrote:
> Hi Moritz,
> 
>> Neil Williams wrote:
>>> It isn't just about choosing not to install it, it causes work for the
>>> various teams in Debian - security, release, QA.
>> We've discussed this at the Security Team meeting in Essen and we don't
>> have a problem with qmail being included in Lenny.
>>
>> Cheers,
>> Moritz
> 
> Thanks, Moritz!  That's great news from the Security Team.
> 
> So, the Security Team has no problem supporting qmail.  Does anyone
> from the Release Team or the QA Teams have any objection to qmail
> being included in Lenny?

We are in a freeze, having the latest release preparations, so
introducing completely new packages in the release is not an option.

I'm also not convinced that introducing yet another MTA which seems
inferior compared to the existing ones in the archive is a very good idea.

Cheers

Luk


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

Re: qmail and related packages in NEW

[Florian Weimer]

* David Kaufman:

> The Security Team has responded that it has no objections to adding
> qmail to Lenny.

Just to clarify, there are no objections with regard to security
support.  This does NOT mean that we want to see qmail in the archive
while there are other open issues (as outlined in the rejection
messaged Jörg forwarded).


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

Re: qmail and related packages in NEW

[Florian Weimer]

* Joerg Jaspert:

>>> It isn't just about choosing not to install it, it causes work for the
>>> various teams in Debian - security, release, QA.=20
>> We've discussed this at the Security Team meeting in Essen and we don't
>> have a problem with qmail being included in Lenny.
>
> Are you aware that qmail and its related packages do have a LOT of code
> duplication?

Personally, I'm more concerned about manual constant propagation in
some parts of the code base (like using the integer literal 4 for the
size of an IPv4 address), and similar coding style issues.  But this
is certainly not restricted to qmail (Bernstein's DNS code suffers
from that to a higher degree, and it's in the archive).  We have such
issues in many, many packages, including recent additions to the
archive.

Like Moritz, I don't see issues with security support, provided that
the number of additional patches is rather small.  (To my knowledge,
badly patched qmail with a SMTP AUTH bypass vulnerability was one of
the few MTAs which were actually exploited to send spam in recent
times.)  I'm also not sure if upstream can be considered dead, and
arguments along that line are not very convincing because similar
criticism could be brought against our default MTA.

I can understand that people have strong feelings.  I'm willing to
provide security support, but it's extremely unlikely that I'll run
qmail on production MTAs ever again. 8-/


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

Re: qmail and related packages in NEW

[Florian Weimer]

* Joerg Jaspert:

> On 11583 March 1977, Gerrit Pape wrote:
>
> As i got asked for the complete text of the rejection mail, as the
> thread start only had a partial quote, here it is.

Thanks!

> First - the packaging is nowhere near the standard Debian aspires to in the
> archive:
>
> Qmail is an MTA and as such should follow Debian Policy (for example Section
> 11.6).  It's therefore not a very good start that an MTA package needs
> additional packages (qmail-run) installed to perform the minimal tasks
> required of mail-transport-agent, and yet another package (fastforward) to
> support /etc/aliases.

Yuck.  I wasn't aware of that.  So the security discussion was kind of
a red herring, after all.


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

Re: qmail and related packages in NEW

[David Kaufman]

[resending, didn't see my last message make it to the list]

Hi Moritz,

"Moritz Muehlenhoff" <[EMAIL PROTECTED]> wrote
>
> Neil Williams wrote:
> > It isn't just about choosing not to install it, it causes work for the
> > various teams in Debian - security, release, QA.
>
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.
>
> Cheers,
> Moritz

Thanks, Moritz!  That's great news from the Security Team.

So, the Security Team has no problem supporting qmail.  Does anyone
from the Release Team or the QA Teams have any objection to qmail
being included in Lenny?

Thanks,

-dave




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

Re: qmail and related packages in NEW

[David Kaufman]

"Neil Williams" <[EMAIL PROTECTED]> wrote:
>
>> Joerg Jaspert wrote:
>>> Aside from these technical - and possibly fixable - problems, we
>>> (as in the ftpteam) have discussed the issue, and we are all of
>>> the opinion that qmail should die, and not receive support from
>>> Debian. As such we *STRONGLY* ask you to reconsider uploading
>>> those packages.

So the "we" in the above statement includes the *entire* FTP Team?  The 
Security Team has responded that it has no objections to adding qmail to 
Lenny.  Who speaks for the QA and Release Teams  (or for that matter, the 
*entire* Debian Developer community, and the user community??)


>>> Qmail is dead upstream

It may be your opinion that qmail is "dead upstream".  My opinion (that of 
the qmail user community, and the original author) is that it works just as 
great now as it did in 1998 and has not needed an update!

>>>and requires a whole set of patches to even begin to work in
>>> the manner expected of a modern MTA.

It needs configuration certainly.  That is what this Debian package would 
provide.

> Packages that are dead upstream are always going to be a headache for
> the security team and the release team. Bit rot is a constant source of
> new bugs as all the packages around the dead one(s) continue to be
> developed and improved.

The Security Team has met and announced that they have no objections to 
adding qmail to Lenny.

Do you offer any other logical (not emotional) reasons that it should not 
be included?

-dave 




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

Re: qmail and related packages in NEW

[David Kaufman]

[resending, b/c I still didn't see my last message make it to the list]

Hi Moritz,

"Moritz Muehlenhoff" <[EMAIL PROTECTED]> wrote
>
> Neil Williams wrote:
> > It isn't just about choosing not to install it, it causes work for the
> > various teams in Debian - security, release, QA.
>
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.
>
> Cheers,
> Moritz

Thanks, Moritz!  That's great news from the Security Team.

So, the Security Team has no problem supporting qmail.  Does anyone
from the Release Team or the QA Teams have any objection to qmail
being included in Lenny?

Thanks,

-dave





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

Re: qmail and related packages in NEW

[David Kaufman]

Hi Moritz,

> Neil Williams wrote:
> > It isn't just about choosing not to install it, it causes work for the
> > various teams in Debian - security, release, QA.
>
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.
>
> Cheers,
> Moritz

Thanks, Moritz!  That's great news from the Security Team.

So, the Security Team has no problem supporting qmail.  Does anyone
from the Release Team or the QA Teams have any objection to qmail
being included in Lenny?

Thanks,

-dave


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

Re: qmail and related packages in NEW

[Mikhail Gusarov]

Twas brillig at 00:40:50 01.12.2008 UTC+01 when [EMAIL PROTECTED] did gyre and 
gimble:

 Md> I need to remind everybody that sadly it is a dependency of Plesk
 Md> (the only high quality administration panel software) so it's still
 Md> going to be installed anyway on many Debian servers.

 Md> Maybe having an official well-maintained package (and the one you
 Md> evalued clearly is not) is the least evil.

[speaking as Plesk ex-developer] It won't help, Plesk's qmail is patched
in various ways, including Plesk-specific patches, so version provided
by Debian won't help.

-- 


pgpe4tUun6pCk.pgp
Description: PGP signature

Re: qmail and related packages in NEW

[Marco d'Itri]

On Nov 30, Joerg Jaspert <[EMAIL PROTECTED]> wrote:

> Qmail is dead upstream and requires a whole set of patches to even begin to
> work in the manner expected of a modern MTA.  Given this, the fact that this
> means there is also no upstream security support, and the fact that Debian
> already contains at least three reasonable MTAs, we see no need to add qmail 
> to
> the archive. So - please reconsider if it really helps Debian to have those
While I totally agree that qmail is an obsolete FPOS with many bad
problems and I hate it with a passion at least as much as any decent
person, I need to remind everybody that sadly it is a dependency of
Plesk (the only high quality administration panel software) so it's
still going to be installed anyway on many Debian servers.
Maybe having an official well-maintained package (and the one you
evalued clearly is not) is the least evil.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Michelle Konzack]

Am 2008-11-28 15:42:34, schrieb William Pitcock:
> I think issues like these call for an unsupported repository outside of
> Debian, but publicized within the community as an unofficial repository
> for things like qmail, packages unwanted in Debian proper for the time
> being, etc.



Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: qmail and related packages in NEW

[Joerg Jaspert]

On 11583 March 1977, Gerrit Pape wrote:

As i got asked for the complete text of the rejection mail, as the
thread start only had a partial quote, here it is.

--88---
From: Joerg Jaspert <[EMAIL PROTECTED]>
Subject: netqmail_1.06-1_powerpc.changes REJECTED
To: Gerrit Pape <[EMAIL PROTECTED]>
Cc: Debian Installer <[EMAIL PROTECTED]>
Date: Sun, 06 Jul 2008 16:19:30 +0200

Hi Maintainer,

rejected, for various reasons (this mail applies to all of the various
qmail and qmail related packages currently in NEW, namely
netqmail, qmail-run, qmail-tools, dot-forward, fastforward).

First - the packaging is nowhere near the standard Debian aspires to in the
archive:

Qmail is an MTA and as such should follow Debian Policy (for example Section
11.6).  It's therefore not a very good start that an MTA package needs
additional packages (qmail-run) installed to perform the minimal tasks
required of mail-transport-agent, and yet another package (fastforward) to
support /etc/aliases.

Now, looking into the binary packages provided by netqmail there are a
*few* points to list:

qmail-uids-gids
  * Uses addgroup in preinst without a pre-depends
  * Uses useradd instead of adduser (policy 9.2.2)
  * Why install the uids/gids in preinst?
  * User interaction without using debconf (policy 3.9.1) in both preinst and
postrm (ok, it's just giving info, but still)
  * Aborts in preinst if:
- "Upgrading" from a pre 1.06 version (presumably unofficial)
- UIDs / GIDs aren't what it expects (as the qmail binary then uses these
  UIDs *it* can't be installed without the UIDs being right, but why does
  qmail-uids-gids fail?)
  * Recommends manual use of userdel and groupdel rather than deluser /
delgroup in postrm 

qmail
  * Installs /var/lib/qmail with alias, bin, boot, queue directories
- Also:
  + users symlink to /etc/qmail/users/
  + control symlink to /etc/qmail/
  + doc symlink to /usr/share/doc/qmail/
- bin/ contains mostly symlinks back to /usr/bin and /usr/sbin but
  one binary is present (config-fast)
- boot/ contains what looks like scripts (should probably be in
  /usr/lib/qmail with a symlink if necessary)
- queue/ is basically the only part which any sane MTA would have in /var

 * Preinst fails if attempting an upgrade from < 1.06 (presumably unofficial)
 * Aborts in postinst if system doesn't have FQDN



Looking at qmail-run there is also:
 * README recommends manually installing non FHS compliant symlinks:
   ln -s /var/lib/qmail /var/qmail
   ln -s /etc/service /service
   Not a policy bug, but certainly in bad taste...
 * C/R/Ps mail-transport-agent
   - Now, this does provide /usr/{sbin,lib}/sendmail
   - But as for /etc/aliases, /usr/sbin/newaliases is:

#!/bin/sh
cat >&2 8---

-- 
bye, Joerg
[...]that almost anything related to "intellectual property" is idiotic
by it's nature, [...]


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Raphael Geissert]

Bas Zoetekouw wrote:
> 
> For completeness sake: QA does not thow out orphanes packages just for
> being orphaned.  If they are orphaned, RC-buggy, hardly used, and
> alternatives are available, only then they are candidates for removal.

You missed Debconf8's BoF I guess.

> 
> Bast regards,
> Bas.
> 

Cheers,
Raphael Geissert


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Gunnar Wolf]

Raphael Geissert dijo [Fri, Nov 28, 2008 at 10:05:23PM -0600]:
> William Pitcock wrote:
> [...]
> > 
> > The ideal way to handle this would be to have a single repository. PPAs
> > solve a different problem, which is giving contributors and developers a
> > playground to publish their in-progress packages. This is more about
> > getting packages to users in an efficient way, for maintainers that do
> > not wish to include those packages in Debian proper for either policy
> > reasons, code quality reasons, or otherwise.
> 
> Solution:
> http://their.domain.tld/debian sid main

The problem there is for this is that people want their work to be
known by more people. Have you seen how outdated apt-get.org is? It
was a valuable resource back then, but... Well, last time I checked,
there were still several Potato backports for software in Woody.

Oh, and right now it has become completely useless - It says it knows
about 1448 sites, but lists only one: http://ftp.debian.org/debian

> Why do people even want to care about those packages?
> I mean, why would one want to use a package which has dubious quality, dubious
> maintenance, dubious origins (can it even be legally distributed/used/etc?),
> dubious ?.
> 
> If a package is not in shape, then get it in shape.
> If they don't know how to setup a simple repository or don't know how to 
> package
> and are not willing to learn, then they should just forget about it and 
> install
> the software by hand (if they know how to do that, of course).
> 
> There's no reason to spend/waste more time/resources on all that extra stuff
> only newcomers will, wrongly, use.

I have to agree with you on this rant, as a DD. However, there are
LOTS of software which are not up to Debian's standards in
this-or-that regard. Having an infrastructure where just about anybody
can upload packages (with just a legality check, I'd say) is positive.

Then again... We can direct them to Ubuntu ;-) They are offering the
service with their PPAs.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Gunnar Wolf]

William Pitcock dijo [Fri, Nov 28, 2008 at 06:57:37PM -0600]:
> (...)
> What I propose is something more along the lines of Gentoo's "sunrise"
> overlay... a repository that anyone can get upload access to provided
> that they understand basic Debian policy and have established that they
> will be non-malicious (likely through some sort of indirect uploading
> for a few months). Basically a true *community* repo.

Umh... If I am malicious, don't you think I will be able to behave for
the first couple of months? Anyway, I don't expect -unsupported
packages to rank very high popcon-wise. I think it will suffice to say
clearly and loudly enough, "this is not Debian, you are using this at
your own risk". Maybe to be as obnoxious with this as to provide an
unsigned archive, so that aptitude (or whatever tool) _always_
complains when installing from there.

Probably the only thing that must be kept (almost?) as strict as it is
in Debian (+non-free) is the licensing checks - Even if it is at
-unsupported, we cannot distribute non-distributable software.

> This would likely be with the packaging source being maintained in SVN,
> so that there is a large amount of transparency in the maintenance
> process.

Yes, having a VCS-based service looks as very important in my eyes.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Gunnar Wolf]

Miriam Ruiz dijo [Sat, Nov 29, 2008 at 02:37:16AM +0100]:
> > DDs would be discouraged from participating since they should be
> > supporting packages/etc within Debian instead.
> 
> I'm not exactly sure about this. I have quite a lot of packages that I
> made for my own usage but I don't have time or interest in maintaining
> on a permanent basis. I guess that's something that happens to more
> DDs out there. We could upload these packages there as: here you are,
> if it's useful for you it's great, but I don't plan on supporting
> this package more than this. Does it make sense?

I agree with Miry here - I also have my personal repository of
packages I often use (i.e. Drupal modules and Munin plugins for work,
or the acerfand fan controlling daemon for my Acer Aspire One) which
I won't maintain in Debian - Why? In some cases, I don't want to
upload something I don't fully trust, and in some, I just know I would
be a lousy maintainer (i.e. I don't grok php, which is used for every
Drupal module - I just use them and want to be able to track them as
packages).

But, yes, it should not promote the idea that "is NEW-processing
taking too long? Just upload to -unsupported!"

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Cyril Brulebois]

Romain Beauxis <[EMAIL PROTECTED]> (29/11/2008):
> Or
>   mentors.debian.net ?

Source-only.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: qmail and related packages in NEW

[Nico Golde]

* Joerg Jaspert <[EMAIL PROTECTED]> [2008-11-29 13:22]:
> 
> >> It isn't just about choosing not to install it, it causes work for the
> >> various teams in Debian - security, release, QA.=20
> > We've discussed this at the Security Team meeting in Essen and we don't
> > have a problem with qmail being included in Lenny.
> 
> Are you aware that qmail and its related packages do have a LOT of code
> duplication?

No. What I see is a lot of reimplemented stuff but not an 
embedded code copy (just had a quick look) which should be 
no problem from my point of view.

> Someone tried to reinvent a libc or something, and just
> copies it into every package. One bug means fixing all 
> those packages at once.

Can you point me to source code? For the reimplemented stuff 
I see no problem, unless its a logical bug this doesn't 
apply.

> And AFAIK thats something the security teams do not like. At least didnt
> in the past.

Well at least this was also not a reason to delete a package 
from the archive so far.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpNwrMY0SuFp.pgp
Description: PGP signature

Re: qmail and related packages in NEW

[Moritz Muehlenhoff]

On 2008-11-29, Joerg Jaspert <[EMAIL PROTECTED]> wrote:
>
>>> It isn't just about choosing not to install it, it causes work for the
>>> various teams in Debian - security, release, QA.=20
>> We've discussed this at the Security Team meeting in Essen and we don't
>> have a problem with qmail being included in Lenny.
>
> Are you aware that qmail and its related packages do have a LOT of code
> duplication? Someone tried to reinvent a libc or something, and just
> copies it into every package. One bug means fixing all those packages at
> once.

Which? AFAICS it has some portability layers and you typically need daemontools
for djbware, but I don't see any horrible code copies.

Cheers,
Moritz


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

Re: qmail and related packages in NEW

[Joerg Jaspert]

>> It isn't just about choosing not to install it, it causes work for the
>> various teams in Debian - security, release, QA.=20
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.

Are you aware that qmail and its related packages do have a LOT of code
duplication? Someone tried to reinvent a libc or something, and just
copies it into every package. One bug means fixing all those packages at
once.

And AFAIK thats something the security teams do not like. At least didnt
in the past.

-- 
bye, Joerg
 anyone from the MIA team around? tbm?
 sounds nice. how long do you have to be MIA to get into that team? :)
 you need to have a pgp key, I suppose. and no gpg one, and only a bo box
 yes, but it must be expired


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Bas Zoetekouw]

Hi Paul!

You wrote:

> basically the Debian answer to Ubuntu's universe. The main reason I
> started thinking about this was that I got annoyed when QA folks chuck
> orphaned packages (i've changed my mind about this since though).

For completeness sake: QA does not thow out orphanes packages just for
being orphaned.  If they are orphaned, RC-buggy, hardly used, and
alternatives are available, only then they are candidates for removal.

Bast regards,
Bas.

-- 
+--+
| Bas Zoetekouw  | Sweet day, so cool, so calm, so bright, |
|| The bridall of the earth and skie:  |
| [EMAIL PROTECTED]  | The dew shall weep thy fall tonight;|
+|For thou must die.   |
 +-+


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

Re: qmail and related packages in NEW

[Moritz Muehlenhoff]

Neil Williams wrote:
> It isn't just about choosing not to install it, it causes work for the
> various teams in Debian - security, release, QA.=20

We've discussed this at the Security Team meeting in Essen and we don't
have a problem with qmail being included in Lenny.

Cheers,
Moritz


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Raphael Geissert]

William Pitcock wrote:
[...]
> 
> The ideal way to handle this would be to have a single repository. PPAs
> solve a different problem, which is giving contributors and developers a
> playground to publish their in-progress packages. This is more about
> getting packages to users in an efficient way, for maintainers that do
> not wish to include those packages in Debian proper for either policy
> reasons, code quality reasons, or otherwise.

Solution:
http://their.domain.tld/debian sid main

Why do people even want to care about those packages?
I mean, why would one want to use a package which has dubious quality, dubious
maintenance, dubious origins (can it even be legally distributed/used/etc?),
dubious ?.

If a package is not in shape, then get it in shape.
If they don't know how to setup a simple repository or don't know how to package
and are not willing to learn, then they should just forget about it and install
the software by hand (if they know how to do that, of course).

There's no reason to spend/waste more time/resources on all that extra stuff
only newcomers will, wrongly, use.

Or do we have so much man power that there's no much left to do but to waste it?

> 
> William

P.S. no need to reply; I just can't stand seeing this topic being brought to
discussion over and over again, always suggesting the same, silly
IMO, "solutions".

Cheers,
Raphael Geissert



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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Romain Beauxis]

Le Friday 28 November 2008 23:57:09 Holger Levsen, vous avez écrit :
> On Friday 28 November 2008 22:42, William Pitcock wrote:
> > I think issues like these call for an unsupported repository outside of
> > Debian, but publicized within the community as an unofficial repository
> > for things like qmail, packages unwanted in Debian proper for the time
> > being, etc.
>
> debian-unofficial.org

Or, why not
  apt-get.org ?
Or
  mentors.debian.net ?

Honnestly, I fail to see clearly the benefit of it, apart from more confusion 
and new issues..

Romain


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Sat, 2008-11-29 at 02:19 +0100, Holger Levsen wrote:
> Hi,
> 
> On Saturday 29 November 2008 01:57, William Pitcock wrote:
> > What I propose is something more along the lines of Gentoo's "sunrise"
> > overlay... a repository that anyone can get upload access to provided
> > that they understand basic Debian policy and have established that they
> > will be non-malicious (likely through some sort of indirect uploading
> > for a few months). Basically a true *community* repo.
> 
> just seen on #debian-community
> 
>  hmmm
>  "community-repo" makes me think we should setup somethink like 
> ubuntus PPA on debian-community.org
>  interesting idea
> * h01ger scratches head

As mentioned on #debian-community, I don't think PPAs are the right way
to address this because PPAs are separate from each other, and therefore
require many sources.list lines.

The ideal way to handle this would be to have a single repository. PPAs
solve a different problem, which is giving contributors and developers a
playground to publish their in-progress packages. This is more about
getting packages to users in an efficient way, for maintainers that do
not wish to include those packages in Debian proper for either policy
reasons, code quality reasons, or otherwise.

William



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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Evgeni Golov]

On Sat, 29 Nov 2008 10:28:58 +0900 Paul Wise wrote:

> Infrastructure should be similarly supported and hosted by mainly
> non-DDs; buildds, porting machines and so on.

Actually I was thinking about something similar yesterday.
Asa non-DD it is very hard to reproduce bugs from arches you don't own,
so why not build a network of buildds, accessible by non-DDs where they
can test their stuff?

Count on me on this, I offer my UltraSparc IIe as a playground :)


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Miriam Ruiz]

2008/11/29 Paul Wise <[EMAIL PROTECTED]>:

> DDs would be discouraged from participating since they should be
> supporting packages/etc within Debian instead.

I'm not exactly sure about this. I have quite a lot of packages that I
made for my own usage but I don't have time or interest in maintaining
on a permanent basis. I guess that's something that happens to more
DDs out there. We could upload these packages there as: here you are,
if it's useful for you it's great, but I don't plan on supporting
this package more than this. Does it make sense?

Greetings,
Miry


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Paul Wise]

On Sat, Nov 29, 2008 at 6:42 AM, William Pitcock
<[EMAIL PROTECTED]> wrote:

> I think issues like these call for an unsupported repository outside of
> Debian, but publicized within the community as an unofficial repository
> for things like qmail, packages unwanted in Debian proper for the time
> being, etc.
>
> That way if people want to run qmail, they can easily get it, but under
> the understanding that it was unofficial and totally unsupported by
> Debian itself. (A debbugs installation could be provided for maintainers
> if necessary though.)
>
> We could also use this repository as a way for teaching new maintainers
> (as an alternative to sponsorship, for the most part) -- packages that
> people use could be cherrypicked out of this archive by DDs who want the
> package in Debian.

I've long been thinking a debian-unsupported.org archive; something
for all those packages that we don't support because they haven't been
good enough to get into Debian or were chucked out of Debian,
basically the Debian answer to Ubuntu's universe. The main reason I
started thinking about this was that I got annoyed when QA folks chuck
orphaned packages (i've changed my mind about this since though).
However, this isn't the only reason I think this is a good idea -
there are lots of packages and package repositories out there that
Debian and our users could benefit from, but that are not up to
scratch enough to support in Debian. Gathering these in one place
would help our users to find packages for software they need but is
unsupported. It would also help Debian get more popcon data about
non-Debian packages and provide a source for rough packages.

Some ramblings about what it might involve:

strictly for packages not in Debian or not updated in Debian - any
package not supported by Debian - it should whine about or reject
directly uploaded packages that have a maintainer or where someone
seems to be "supporting" a particular package by doing lots of
uploads.

automatic merging of packages removed from Debian and packages
uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other
Debian-based distros that have public archives.

addition of automatically created packages using the tool that was
recently posted about on debian-devel

software would be a combination of dak, ubuntu's merge-o-matic (or
similar), maybe debbugs, pdo, pts, patches.u.c, maybe DDPO, buildd
stuff, lintian and perhaps others.

DDs would be discouraged from participating since they should be
supporting packages/etc within Debian instead.

Allow uploads from DDs, DMs, NMs, DD-connected mentors.d.n keys,
DD-connected REVU keys, Ubuntu developer keys, Ubuntu MOTU keys and
people in a separate MOTU (master of the unsupported) keyring that is
relatively easy to get into.

Infrastructure should be similarly supported and hosted by mainly
non-DDs; buildds, porting machines and so on.

not sure if integrating debian-ports.org there is appropriate or not,
but maybe it would be a good idea later down the track.

A while ago on -devel there was a post about automatic creation of
rough packages using automatic software discovery and AI techniques
for the packaging, I definitely want to feed that into this idea.

Once all the repositories are merged into one place, then we can
export all their patches against debiann to merge.debian.net and have
that linked from the PTS like patches.ubuntu.com is. More about that
idea here:

http://wiki.debian.org/MergeDerivedDistributions

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Holger Levsen]

Hi,

On Saturday 29 November 2008 01:57, William Pitcock wrote:
> What I propose is something more along the lines of Gentoo's "sunrise"
> overlay... a repository that anyone can get upload access to provided
> that they understand basic Debian policy and have established that they
> will be non-malicious (likely through some sort of indirect uploading
> for a few months). Basically a true *community* repo.

just seen on #debian-community

 hmmm
 "community-repo" makes me think we should setup somethink like 
ubuntus PPA on debian-community.org
 interesting idea
* h01ger scratches head


regards,
Holger

Disclaimer: I have absolutly not the ressources to do this or help much with 
doing it. But I probably like to see this very much... /me needs sleep.

BTW, d-c.org finally (since a bit of time) provides email and jabber accounts 
for Debian contributors!


pgpHp1mFkKzkX.pgp
Description: PGP signature

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Fri, 2008-11-28 at 23:57 +0100, Holger Levsen wrote:
> Hi,
> 
> On Friday 28 November 2008 22:42, William Pitcock wrote:
> > I think issues like these call for an unsupported repository outside of
> > Debian, but publicized within the community as an unofficial repository
> > for things like qmail, packages unwanted in Debian proper for the time
> > being, etc.
> 
> debian-unofficial.org

There's a few problems with debian-unofficial.org, as I see it:

1. It has the same quality requirements as Debian proper in terms of
packaging and code quality -- in my way of interpreting things, qmail
would not be acceptable here;
2. I believe, but may be wrong, that [EMAIL PROTECTED] is the only person who
can actually add anything to it. So if daniel does not like qmail for
example, it would not be added.

What I propose is something more along the lines of Gentoo's "sunrise"
overlay... a repository that anyone can get upload access to provided
that they understand basic Debian policy and have established that they
will be non-malicious (likely through some sort of indirect uploading
for a few months). Basically a true *community* repo.

This would likely be with the packaging source being maintained in SVN,
so that there is a large amount of transparency in the maintenance
process.

William


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

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[Holger Levsen]

Hi,

On Friday 28 November 2008 22:42, William Pitcock wrote:
> I think issues like these call for an unsupported repository outside of
> Debian, but publicized within the community as an unofficial repository
> for things like qmail, packages unwanted in Debian proper for the time
> being, etc.

debian-unofficial.org


regards,
Holger


pgpoyQt9XL95B.pgp
Description: PGP signature

what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

[William Pitcock]

Hi,

On Fri, 2008-11-28 at 20:51 +0100, Neil Williams wrote:
> > Can you advise me on how to get out of that dilemma?
> 
> Stop trying to get qmail into Debian?
> or
> Take on upstream development of qmail and solve all the problems
> (whether qmail will then be recognisable compared to the existing
> packages that do the same job, I have no idea).
> 

I think issues like these call for an unsupported repository outside of
Debian, but publicized within the community as an unofficial repository
for things like qmail, packages unwanted in Debian proper for the time
being, etc.

That way if people want to run qmail, they can easily get it, but under
the understanding that it was unofficial and totally unsupported by
Debian itself. (A debbugs installation could be provided for maintainers
if necessary though.)

We could also use this repository as a way for teaching new maintainers
(as an alternative to sponsorship, for the most part) -- packages that
people use could be cherrypicked out of this archive by DDs who want the
package in Debian.

Thoughts?

William


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

Re: qmail and related packages in NEW

[Neil Williams]

On Fri, 28 Nov 2008 18:12:42 +
Gerrit Pape <[EMAIL PROTECTED]> wrote:

> Hi, I'm quite surprised how the inclusion of qmail and related
> packages into sid is handled, or rather not handled, by the
> ftpmasters.

Just because a package is free software does not mean it automatically
qualifies for inclusion in Debian. Debian is not a dumping ground for
every piece of free software that can be dragged off long-dead
homepages.

> Lacking any response, I can only guess what the reason for the delay
> is.

IMHO, the response has been given and your replies have not provided
sufficient grounds to change the response. Personally, I think that is
entirely fair.

> >From my point of view this reason is questionable, and I stated so
> >in my
> response to the reject mail.  Receiving no response within eight weeks
> tells me that discussing doesn't work.

Discussions only work when new information is available. Rehashing the
same points in the hope that repetition wins the day is just boring.
 
> On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote:
> > On Sun, Jul 06, 2008 at 02:19:30PM +, Joerg Jaspert wrote:
> > > Aside from these technical - and possibly fixable - problems, we
> > > (as in the ftpteam) have discussed the issue, and we are all of
> > > the opinion that qmail should die, and not receive support from
> > > Debian. As such we *STRONGLY* ask you to reconsider uploading
> > > those packages.
> > >
> > > Qmail is dead upstream and requires a whole set of patches to even
> > > begin to work in the manner expected of a modern MTA.  Given
> > > this, the fact that this means there is also no upstream security
> > > support, and the fact that Debian already contains at least three
> > > reasonable MTAs, we see no need to add qmail to the archive. So -
> > > please reconsider if it really helps Debian to have those
> > > packages. Also feel free to start a public discussion on
> > > debian-devel@lists.debian.org about the issue, including any
> > > relevant information from this email, in order to gather opinions
> > > from other project members.

To me, that sounds like a perfectly reasonable and calm response to
your original question.

Packages that are dead upstream are always going to be a headache for
the security team and the release team. Bit rot is a constant source of
new bugs as all the packages around the dead one(s) continue to be
developed and improved.

> > We all know, I guess, that there's lots of different opinions on the
> > quality and usability of qmail.  There're people thinking like you,
> > and other people, including me, that have a different opinion.  I
> > respect your opinion, please respect ours too.  You're free to not
> > install/use the packages.  I've been contacted by several people
> > since I announced my intention to package qmail, speaking in favor
> > of the inclusion into Debian.

It isn't just about choosing not to install it, it causes work for the
various teams in Debian - security, release, QA. 

There are always different opinions. What matters is whether there is
any new information to bring to the discussion.

> > I think your advise to start a discussion to gather support for the
> > packages is backwards.  Debian is about free software and users, the
> > qmail packages are free software, and users request the inclusion
> > into Debian. 

Insufficient. Debian is about quality, not merely quantity.

> > If you are interested in not having qmail in Debian,
> > you are free to start a public discussion to find supporters for
> > your position, I guess you'll get some objections too.

IMHO qmail should continue to be rejected for the reasons explained by
the original rejection response.

(This package is dead, it's joined the bit bucket invisible, it's been
left unwanted and unmaintained by the upstream. Having a debian
maintainer is insufficient - what qmail needs is a new upstream team.)

> I've no idea where yet another thread on this list should take us.

Hopefully, it will convince you that qmail has no place in Debian
until someone thinks it is worth breathing some life into the upstream
code.

> To me the situation is clear.  There's a user base for these
> packages, and a Debian developer ready to maintain them.

Insufficient.

> In my opinion, ftpmasters should reject packages on grounds of Debian
> policy or (maybe) the Debian body.  If they wish a permanent
> rejection of qmail and related packages, they should try to find that
> consensus within Debian, and, if successful, add that decision to
>  http://www.debian.org/devel/wnpp/unable-to-package
> 
> Can you advise me on how to get out of that dilemma?

Stop trying to get qmail into Debian?
or
Take on upstream development of qmail and solve all the problems
(whether qmail will then be recognisable compared to the existing
packages that do the same job, I have no idea).

-- 


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

Re: qmail

[Josip Rodin]

On Mon, Aug 21, 2000 at 01:28:40PM -0500, Chris Lawrence wrote:
> > Debian officially recommends something?  That's news to me.
> 
> I believe we ship exim as the "standard" MTA (we changed from smail in
> hamm or slink); I don't know if that makes it recommended or not.

It makes it recommended for new users, that's all, IIRC.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: qmail

[Chris Lawrence]

On Aug 21, Dan Brosemer wrote:
> Debian officially recommends something?  That's news to me.

I believe we ship exim as the "standard" MTA (we changed from smail in
hamm or slink); I don't know if that makes it recommended or not.

Personally, I'd like to see postfix as the standard MTA, but we'd need
something like eximconfig for it first.


Chris

Re: qmail

[Colin Watson]

Niall Young <[EMAIL PROTECTED]> wrote:
>What's the official stance on qmail?  Is the licence (or lack thereof?)
>too restrictive (any modified versions can't be distributed without
>approval)?

Yep. If you have a look at:

  http://www.debian.org/Packages/stable/mail/qmail-src.html

... you'll see the following paragraph:

   Dan Bernstein (qmail's author) only gives permission for qmail to be
   distributed in source form, or binary form by approval. This package
   has been put together to allow people to easily build a qmail binary
   package for themselves, from source.

DJB has a habit of coming up with almost-free but restrictive licences.
:( Any questions about those would probably be best answered on
debian-legal.

-- 
Colin Watson [EMAIL PROTECTED]

Re: qmail

[Dan Brosemer]

On Mon, Aug 21, 2000 at 01:58:07PM +0800, Niall Young wrote:
> What's the official stance on qmail?  Is the licence (or lack thereof?)
> too restrictive (any modified versions can't be distributed without
> approval)?  

Yeah, that'll do it.  See
http://www.debian.org/doc/debian-policy/ch2.html#s-pkgcopyright

>I notice that qmail-src_1.03-14.deb and qmail_1.03-14.dsc are
> in non-free - any reason that binary packages haven't been made (yes I
> know that qmail-src comes with compile scripts)?  

You said it yourself:  "modified versions can't be distributed without
approval".  Debian doesn't seek special status.  It's part of Debian's
policy.

>   Any issues or opinions
> on qmail?

I'll neatly try to avoid a flame war by not expressing my own opinion, but
I'll point you at someone else's.

http://linux.umbc.edu/lug-mailing-list/1999-04/msg00096.html

> I've recently migrated from RedHat (and loving it) and while I'd prefer to
> stick with what Debian officially recommends, qmail has some features that I
> prefer.  Anyone got any good arguments against qmail?

Debian officially recommends something?  That's news to me.

-Dan

-- 
"... the most serious problems in the Internet have been caused by 
unenvisaged mechanisms triggered by low-probability events; mere human 
malice would never have taken so devious a course!" - RFC 1122 section 1.2.2


pgpukdKVMiezk.pgp
Description: PGP signature

Re: Qmail, smail and sendmail

[Ian Jackson]

Yves Arrouye writes ("Re: Qmail, smail and sendmail"):
...
> That's what I do. I even run sendmail -bi if newaliases is not found.
> But I wanted to be sure that all mail packages do provide the same
> user way of defining aliases, even if they manage them differently after
> that.

I'll specify in the mail processing section of the polcy manual:
 /etc/aliases is the source file for the system mail aliases
 (e.g.  postmaster, usenet, etc.) - it is the one which the sysadmin
 and postinst scripts may edit.  After /etc/aliases is edited
 the program or human editing it must call 

Ian.

Re: Qmail, smail and sendmail

[Yves Arrouye]

Ian Jackson writes:
 > Yves Arrouye writes ("Qmail, smail and sendmail"):
 > > Does qmail support /etc/aliases, have a newaliases command and support
 > > being called as sendmail with the -bi option?
 > > 
 > > The same questions may be asked for smail.
 > 
 > Well, perhaps we should just say that you can edit /etc/aliases and
 > must run newaliases afterwards if it exists.

That's what I do. I even run sendmail -bi if newaliases is not found.
But I wanted to be sure that all mail packages do provide the same
user way of defining aliases, even if they manage them differently after
that.

Yves.

Re: Qmail, smail and sendmail

[Ian Jackson]

Yves Arrouye writes ("Qmail, smail and sendmail"):
> I'd like to know if there's a qmail Debian package, and how aliases
> work in qmail: the Apache package used to add an alias to /etc/aliases
> and then run sendmail -bi (or newaliases).
> 
> Does qmail support /etc/aliases, have a newaliases command and support
> being called as sendmail with the -bi option?
> 
> The same questions may be asked for smail.
> 
> Is the answer is no, can you please email me some doc? And maybe we'll
> have to write an install-mail-alias command used by packages script, in
> this case.

Well, perhaps we should just say that you can edit /etc/aliases and
must run newaliases afterwards if it exists.

Ian.