Re: Bug#457318: qmail and related packages in NEW
Gerrit Pape [EMAIL PROTECTED] writes: So it might well be that those SMTP servers, that accept mail regardless of the existence of the recipient mailbox, take load off your server's spam processing, because they eat spammer's resources. I rather use a MTA that implements SMTP time delays to force the spammer to slow down, thank you very much. I even endorse greylisting (with a whitelist) nowadays, but you'll never see me endorsing QMail until it is patched. Concerning the delayed delivery notifications, there's an efficient way to immediately reject those in the SMTP connection, see I rather not force other mail admins to implement measurements to deal with another MTA's stupidity. -- * 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: qmail and related packages in NEW
This one time, at band camp, Gerrit Pape said: Finally, just as not supporting VRFY, not rejecting in the SMTP conversation makes it harder for the spammers to sort out bad recipient addresses, and so to use their resources even more efficiently. That is so stunningly wrong an argument I can't even think of anything to say. Are you sure you should be working with MTA software? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#457318: qmail and related packages in NEW
Hi, On Thu, Dec 04, 2008 at 11:05:31AM +0100, Florian Weimer wrote: Out of curiosity, does netqmail fix at least the delayed bounce problem? no, or maybe: not yet; they gave notice of including that, but nothing happened yet http://marc.info/?l=qmailm=120275739720434w=2 On Thu, Dec 04, 2008 at 11:44:41AM +0200, Kalle Kivimaa wrote: Gerrit Pape [EMAIL PROTECTED] writes: I've yet to be pointed to a grave or serious bug in the packages pending in NEW, otherwise I see no reason why they shouldn't be processed and pass NEW. I completely agree with this well written post Does the package in NEW fix the well known backscatter spam issue? I tried searching for the fix in the package but unfortunately failed. Not the default install. The package includes a patch though, and builds and provides additional smtpd and qmtpd replacements that reject unknown addresses in the SMTP connection, they're trivial to enable. I personally use mailfront instead of qmail-smtpd. mailfront, already available in Debian/main, has this functionality and can also act perfectly as a replacement. If it doesn't, then IMO, at this day and age, a MTA sending backscatter spam doesn't belong to Debian. I understand that opinion, and almost share it, after all I've configured my servers that way too. I'd prefer to have that changed upstream in netqmail, but am not strictly opposed to making that change for Debian explicitly. Why 'almost share it'? Rejecting in the SMTP connection also plays into the hands of spammers. They have some resources available to blast out data of unsolicited mails. Once an SMTP server rejects a recipient before DATA, the SMTP client doesn't need to transmit the data, and can immediately switch to another recipient, using the resources more efficiently. The more SMTP servers reject on RCPT, the more moves the load to other SMTP servers. So it might well be that those SMTP servers, that accept mail regardless of the existence of the recipient mailbox, take load off your server's spam processing, because they eat spammer's resources. Concerning the delayed delivery notifications, there's an efficient way to immediately reject those in the SMTP connection, see http://lists.debian.org/debian-isp/2004/09/msg00080.html Finally, just as not supporting VRFY, not rejecting in the SMTP conversation makes it harder for the spammers to sort out bad recipient addresses, and so to use their resources even more efficiently. That not necessarily needs to be true; it's theory, but in my opinion it's worth thinking about. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: qmail and related packages in NEW
On Tue, Dec 02, 2008 at 11:29:13AM +0100, Bjørn Mork wrote: Gerrit Pape [EMAIL PROTECTED] writes: Hi, I'm quite surprised how the inclusion of qmail and related packages into sid is handled, or rather not handled, by the ftpmasters. I downloaded the netqmail source from http://dbn.smarden.org/sid/ and looked briefly at it, to see if most of the well-known (some of the for 10+ years!) bugs have been fixed. Unfortunately, it doesn't seem so. The Debian packaging included surprisingly few patches, and the fixes I tested still applies to the Debian package. e.g: [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run ../patch-qmail-1.03-rfc2821.diff patching file qmail-remote.c [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run ../patch-qmail-1.03-rfc1652.diff patching file ./qmail-smtpd.c Hunk #1 succeeded at 229 with fuzz 1. To avoid having packages starting their Debian life with a long list of serious and grave bugs, may I suggest that you take a look at http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [1] and either include the patches or use the suggested workarounds? Sure, the two patches you mention might be considered for Debian. However, I wonder how two issues can be called a 'long list', and how these can be judged as severity grave or serious. Right now, upstream doesn't completely agree with Andree's list of bugs. Do you know how many people add accept_8bitmime to the default exim configuration, and for what reason? Do you know why any highest priority MX with the closest distance to the mail store should issue temporary errors on incoming connections permanently, and whether this is okay with the standards? I've yet to be pointed to a grave or serious bug in the packages pending in NEW, otherwise I see no reason why they shouldn't be processed and pass NEW. I completely agree with this well written post http://lists.debian.org/debian-devel/2008/12/msg00207.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: qmail and related packages in NEW
Gerrit Pape [EMAIL PROTECTED] writes: I've yet to be pointed to a grave or serious bug in the packages pending in NEW, otherwise I see no reason why they shouldn't be processed and pass NEW. I completely agree with this well written post Does the package in NEW fix the well known backscatter spam issue? I tried searching for the fix in the package but unfortunately failed. If it doesn't, then IMO, at this day and age, a MTA sending backscatter spam doesn't belong to Debian. -- * 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: qmail and related packages in NEW
* Gerrit Pape: Right now, upstream doesn't completely agree with Andree's list of bugs. Out of curiosity, does netqmail fix at least the delayed bounce problem? -- 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? :) 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
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: Bug#457318: qmail and related packages in NEW
Gerrit Pape [EMAIL PROTECTED] writes: Hi, I'm quite surprised how the inclusion of qmail and related packages into sid is handled, or rather not handled, by the ftpmasters. I downloaded the netqmail source from http://dbn.smarden.org/sid/ and looked briefly at it, to see if most of the well-known (some of the for 10+ years!) bugs have been fixed. Unfortunately, it doesn't seem so. The Debian packaging included surprisingly few patches, and the fixes I tested still applies to the Debian package. e.g: [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run ../patch-qmail-1.03-rfc2821.diff patching file qmail-remote.c [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run ../patch-qmail-1.03-rfc1652.diff patching file ./qmail-smtpd.c Hunk #1 succeeded at 229 with fuzz 1. To avoid having packages starting their Debian life with a long list of serious and grave bugs, may I suggest that you take a look at http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [1] and either include the patches or use the suggested workarounds? Bjørn [1] This page refers to http://home.pages.de/~mandree/qmail-bugs.html as its canonical location but I'm currently unable to open the latter -- 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 [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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
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
[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
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
[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
* 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: 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
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
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
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? 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
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
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: qmail and related packages in NEW
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
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)
Romain Beauxis [EMAIL PROTECTED] (29/11/2008): Or mentors.debian.net ? Source-only. Mraw, KiBi. signature.asc Description: Digital signature
Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
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)
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)
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 insert whatever you want here?. 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)
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: qmail and related packages in NEW
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.
--8schnipp-8---
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 EOT
qmail on Debian by default doesn't support the /etc/aliases database,
but handles mail aliases differently, please see
http://lifewithqmail.org/lwq.html#aliases
EOT
exit 1
which breaks policy 11.6
* Why is qmailctl in /usr/bin?
* preinst break on upgrades *AGAIN*
* postinst errors if no FQDN
* No man pages:
lintian check for qmail-run_2.0.0_all.deb
W: qmail-run: binary-without-manpage usr/sbin/mailq
W: qmail-run: binary-without-manpage usr/sbin/newaliases
W: qmail-run: binary-without-manpage usr/bin/qmailctl
W: qmail-run: binary-without-manpage usr/sbin/sendmail
dot-forward only has
* Lots of code duplication from netqmail in the supporting code (alloc
routines etc). Apparently djb hasn't heard of libraries.
And finally qmail-tools:
* Native tarball contains upstream tarball for queue_repair.py
* Package mainly to help with upgrading from non-free / unofficial packages,
but the scripts just state that it isn't supported...
* So only use is queue_repair.py; why native?
* /usr/sbin/queue_repair is a horribly generic name
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.
--8schnapp-8---
--
bye, Joerg
[...]that almost anything related to intellectual property is idiotic
by it's nature, [...]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
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. http://www.apt-get.org/ 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
qmail and related packages in NEW
Hi, I'm quite surprised how the inclusion of qmail and related packages into sid is handled, or rather not handled, by the ftpmasters. Within a time-frame of six months I received exactly one rejection mail in response to two uploads of the packages, a reply to the rejection mail, and three mails asking about the progress because nothing happened. http://smarden.org/pape/Debian/sid.html#nonprogress Mon, 28 Apr 2008: uploaded packages to ftp-master. Tue, 03 Jun 2008: no response, asking for progress. Tue, 17 Jun 2008: no response, asking again. Sun, 06 Jul 2008: received this REJECT email. Mon, 01 Sep 2008: uploaded updated packages to NEW, and sent a reply. Tue, 11 Nov 2008: no response, asking for progress. Thu, 20 Nov 2008: no response. Today: still no response. Lacking any response, I can only guess what the reason for the delay is. 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. 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. 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. A public discussion already took place http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/ 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. 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. I've no idea where yet another thread on this list should take us. To me the situation is clear. There's a user base for these packages, and a Debian developer ready to maintain them. I count at least three Debian developers speaking in favor of the inclusion, I've been approached by several users asking me to make my unofficial packages officially available in Debian, another Debian developer has a package depending on qmail in the NEW queue. 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? Thanks, Gerrit. See http://bugs.debian.org/457318 http://smarden.org/pape/Debian/sid.html#nonprogress http://ftp-master.debian.org/new.html http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/ for all the details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
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.ms/ pgpdiudfdQMpW.pgp Description: PGP signature
what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
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: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
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
Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
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)
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 h01ger hmmm h01ger community-repo makes me think we should setup somethink like ubuntus PPA on debian-community.org h01ger 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)
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)
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)
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)
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 h01ger hmmm h01ger community-repo makes me think we should setup somethink like ubuntus PPA on debian-community.org h01ger 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)
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 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 insert whatever you want here?. 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]
