Bug#309048: several security issues on 64 largemem systems (CAN-2005-1515, CAN-2005-1514, CAN-2005-1513O
Quoting Joey Hess <[EMAIL PROTECTED]>: > Package: qmail-src > Severity: important > Tags: security > > Apparently qmail has some security bugs on 64 bit systems with large > amounts (> 4 gb) of memory: > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1515 > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1514 > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1513 Thanks for the report Joey. I'll start digging into it immediately. Have you heard/seen any mention of a possible fix/patch? Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309048: several security issues on 64 largemem systems (CAN-2005-1515, CAN-2005-1514, CAN-2005-1513O
Quoting Joey Hess <[EMAIL PROTECTED]>: > Package: qmail-src > Severity: important > Tags: security > > Apparently qmail has some security bugs on 64 bit systems with large > amounts (> 4 gb) of memory: > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1515 > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1514 > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1513 I looked into this a bit more, and there is no real security concern here. It is possible to get qmail to crash from resource exhaustion, but you can do that to just about anything. The "exploit" can only manage to -*potentially*- overwrite a single byte. The chances of using this for arbitrary code execution do not exist. There is some heated discussion going on in the qmail lists (read as flamewars) regarding this issue. Apparently, the person who reported this likes to pop up every now and then screaming "the sky is falling" with some kind of arbitrary "security advisory" that usually ends up being nothing. He's attacked qmail in a similar fashion before discovering that on a 64-bit system, you can cause qmail-smtpd to segfault by sending a 2GB header. The whole problem revolves around the idea that on some platforms, an integer is 32-bit, while a memory pointer can be 64-bit. QMail was coded such that integers and pointers are interchangable, thus leading to the potential benign crashes. In the qmail list, the general concensus seems to be that using ulimits prevents the crash from happening in the first place. Luckily for me, I am using ulimits in the init.d script for starting qmail. From the init.d script: --snip-- # prevent denial-of-service attacks, with ulimit ulimit -v 16384 --snip-- This limits the amount of memory that qmail-smtpd and tcpserver can use to 16MB. This should be enough to stop any DoS attacks, or potential exploit attempts. I've gone a step further, and included the ISO C patch as well, to add another layer of protection. The only affects from the patch should be to mitigate any exploit not prevented by the ulimits (which can be removed by the sysadmin). The patch is included in -38 which will be uploaded today. Thanks again for the heads up. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293328: Fwd: Bug#293328: qmail-src: use tcpsvd instead of tcpserver
I received the following wishlist bug today, and really like the idea. My thoughts are to change the dependancies to allow ipsvd to be used in place of ucspi-tcp and ucspi-tcp-src. I'll need to do some "magic" to get the init.d file to work properly, but I can just make that a build-time debconf option, or add some "intelligence" into the build script. I'll probably want to add a build-dependancy on ipsvd or ucspi-tcp as well to ensure that the intelligence works properly. Can you think of any other things that I may need to consider? I don't want to do a complete daemontools packaging, just a "drop-in-replacement" of ucspi-tcp. Cheers! Jon - Forwarded message from Bastian Kleineidam <[EMAIL PROTECTED]> - Date: Wed, 02 Feb 2005 16:26:10 +0100 From: Bastian Kleineidam <[EMAIL PROTECTED]> Reply-To: Bastian Kleineidam <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Bug#293328: qmail-src: use tcpsvd instead of tcpserver To: Debian Bug Tracking System <[EMAIL PROTECTED]> Package: qmail-src Version: 1.03-36 Severity: wishlist Hi, the tcpsvd program is a free drop-in replacement for tcpserver. It would be nice to use it (located in the ipsvd package) instead of having to install and compile ucspi-tcp from the -src package. Regards, Bastian -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-treasure3 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages qmail-src depends on: ii debconf 1.4.42 Debian configuration management sy ii dpkg-dev 1.10.26Package building tools for Debian ii fakeroot 1.2.4 Gives a fake root environment ii gcc 4:3.3.5-1 The GNU C compiler ii groff-base1.18.1.1-6 GNU troff text-formatting system ( ii make 3.80-9 The GNU version of the "make" util ii patch 2.5.9-2Apply a diff file to an original ii sudo 1.6.8p5-1 Provide limited super user privile -- debconf information: * qmail-src/ucspitcp: * qmail-src/warning: * qmail-src/build: - End forwarded message - --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302677: qmail: FTBFS: Missing Build-Depends on 'groff-base' and missing users and groups
Quoting Tomas Hoger <[EMAIL PROTECTED]>: > Hi! > > > I think it is an FTBFS bug. The following should generally work: > > > > apt-get source qmail > > cd qmail-* > > dpkg-buildpackage > > > > For qmail, this does not work because of the missing Build-Depends on > > groff-base and because of the missing users/groups. > > Those are needed to create 'qmail-src'. It should be possible to > > build the 'qmail-src' package. > > Yes, you're right. I missed one point: it's also FTBFS for qmail-src, > not only for qmail (and caused by qmail). My mistake! > > Hopefully, someone will be able to upload new version soon. I will be uploading a new version that should keep everyone happy in the next day or so. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302677: Fix for missing build-depends
I am including a fix for the missing build-depends line in the control file. However, I am not changing how the package presently handles creating the users. qmail-src is not in the main package repository. It's in the non-free repository, which, in reality, means it's not officially part of Debian. It's a quick package that, when used properly, allows you to hack some non-free software into your Debian system (tainting it) with a minimal amount of effort. It's not a very well liked package among many with Debian as there is bad blood between Debian and DJB ... not to mention DJB's hostility towards the OSS community in general, and the lack of any kind of offical license for qmail. That said, it's working as designed, and I am taking steps to correct the missing Build-Depends line. I will close the bug out after -37 has been uploaded. Any additional request to change the user/group mechanism will be handled seperately. In all reality, they are two separate issues. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#282932: Other location?
Do you have another location for that patch, or perhaps more information? I've been unable to get to that URL, or find a different patch than the one included. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326415: Please support IPv6 or Advertise lack
Quoting Elliott Mitchell <[EMAIL PROTECTED]>: > Sendmail definitely supports IPv6, and I strongly suspect Postfix does as > well. This makes Qmail the unusual one in /not/ supportting IPv6. Given > the increasing prevalence of support, I'd suggest either documenting the > lack of support or including the Qmail IPv6 patch. IPV6 support is not presently required for MTA's in Debian, regardless of how many other MTA's do support IPV6. I'm marking this as a wishlist bug for further consideration in a future release. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#57102: ucspi-tcp-src: This is severe bug, and wrongly categorized as a wish list item
Quoting G A Craig Carey <[EMAIL PROTECTED]>: > Package: ucspi-tcp-src > Version: 0.88-9 > Followup-For: Bug #57102 > > After years of having "." at the start of the PATH, it > eventually one problem can be discovered: the install of > just this package fails. I really don't understand how having a broken, insecure PATH configuration is a severe bug with ucspi-tcp-src. With a configuration like that, you've got much bigger problems than ucspi-tcp-src not building. Cheers! Jon --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402331: FTBFS: "unable to find user alias"
Quoting Thomas Huriaux <[EMAIL PROTECTED]>: > Jon Marler <[EMAIL PROTECTED]> (21/12/2006): > > Quoting Thomas Huriaux <[EMAIL PROTECTED]>: > > > Note also that once this is fixed, you should update the description of > > > the qmail-src package. > > > > I am not exactly sure what pbuilder is doing here, but I don't get the same > > behavior when executing "debian/rules binary" to build -*just*- the > qmail-src > > package. If you are trying to build the qmail package as well, you will > have > > to have the users. Period. > > I am not trying to build the qmail package, I am trying to build the > only package listed in debian/control, i.e. the qmail-src package. > It still fails. > > See Steve's answer: > The problem seems to be that your debian/rules is misusing the > binary-arch and binary-indep targets for purposes other than building > the packages listed in debian/control. > > > > "qmail" is not an "official" Debian package. "qmail-src" is an "official" > > Debian non-free package. > > > > I believe that the problem here is that your default invocation of pbuilder > is > > attempting to build both the qmail-src and the qmail packages, which are > two > > separate things. > > > > I did find where attempting to build the qmail-src package would require > the > > users, and I have fixed that bug. It appears that you are now reporting > the > > same error, with a different package, that is not part of Debian. > > > > Please separate out the two. As far as I can tell, I have fixed the bug in > > qmail-src. The remaining complaint about the qmail package is moot, as > qmail > > is not part of Debian. > > > > Also, I do not see where or why I need to update the description of the > > qmail-src package. Update what exactly? If you want a change in the > > description, please file a different bug report. > > Because > If you try "apt-get source --build qmail-src" it will most likely fail > because the users do not exist. You MUST install the qmail-src > package first. > won't be true anymore once your package is fixed. This seems to be > closely related enough to not deserve a new bug. I see what pbuilder is doing now. I wasn't testing it that way ... pbuilder, and dpkg-buildpackage both execute debian/rules build, rather than debian/rules binary. This is the crux of my problem. My debian/rules build command would build the binary package, and the -src package, rather than just the -src package. Look in the archive for -42. It should build now with apt-get source -b, dpkg-buildpackage, and pbuilder. Hopefully this release will put this bug to rest. I have also updated ucspi-tcp-src with a similar fix, just to head you off at the pass ;) I have also updated the control file, as suggested. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406990: qmail: please finish /usr/doc transition
Quoting Thijs Kinkhorst <[EMAIL PROTECTED]>: > Package: qmail > Tags: patch > > Hi, > > qmail still creates a /usr/doc symlink. Since 2002, policy > has not required these symlinks, and we're waiting for all packages > to be updated to remove them before the /usr/share/doc transition can > be complete. This package is one of the few packages that still makes > the symlink. > > If your package uses debhelper, you should be able to fix this bug by > simply rebuilding the package. If it does not, you should remove the > symlink management code from your maintainer scripts. If the symlink > creation code was implemented properly before, your package should > remove the old symlinks in its postrm when upgraded. If you don't use > debhelper (or even if you do), please check that the symlink is gone > after upgrade. > > Please see bug #322762 for some more details. > > I've attached a patch to accomplish this. Note that the 1.02 upgrading > section also contained references to /usr/doc. Since upgrading from 1.02 > directly is not supported anymore (that's from 1998) I thought it better > to just remove that section. > > If you need help, or would like an NMU, please say so. > > By the way, you could take a look at the warnings that lintian emits, I > think it indicates more possible improvements for the package. I love quality bug reports with quality patches! Thank you very much, I have applied your patch in full, and you should see the changes in -43. Qmail was removed from testing for an RC bug that I have fixed, and a regression, but I am working on getting that repaired. This release should help in that regard. I have also made a couple more updates that should clear up some of those lintian errors. Thanks again! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351394: All debconf stuff can probably be cleaned from the qmail package
Quoting Thomas Huriaux <[EMAIL PROTECTED]>: > I don't see any reason to close this bug. If you don't want to fix this > issue, please tag it as wontfix. > > In order to have this bug fixed, I wrote a full patch. Here are my > comments on the debconf templates, as the rest just depends on these > fixes: The reason to close this bug is that is has been fixed. The problem was that I included information using debconf that didn't need to be there. All of the qmail-src debconf entries did not fit the policy, and have been removed. I am the package maintainer, and I am allowed to make decisions on what information is included and displayed when the package is installed. I have decided that my previous use of debconf has been deprecated, and therefore, I have no further use for debconf. In fact, I have removed all dependency on debconf from qmail-src. I won't close this bug, but I'll move it to the wishlist. The package does not violate the "spirit" of what debconf was intended for, or any Debian policies, or even interact in any way with debconf. Technically, what you are now asking, is that I add in new debconf support. Thank you for the suggestion, I will add it to the wishlist. If that is not enough to placate you, please feel free to waste more of everyone's time and whine on. Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402339: ucspi-tcp-src: Should not stop installation with usage instructions
Quoting Thomas Huriaux <[EMAIL PROTECTED]>: > Package: ucspi-tcp-src > Version: 0.88-10 > Severity: normal > > While installing ucspi-tcp-src, my installation stopped with: > > To build ucspi-tcp binary package, you have to run > >build-ucspi-tcp > > Press ENTER to continue... > > According to policy 3.9, > * prompting the user by hand is deprecated > * displaying instructions on how to use a program during the > installation is inappropriate. Never a dull moment with Debian ... Be watching for an updated release to remove the pause, and offending message. How this will make the distribution better is beyond me ... but I'll do it. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402331: FTBFS: "unable to find user alias"
Quoting Stephen Gran <[EMAIL PROTECTED]>: > I think you are letting your crankiness interfere with your logic. The > people arguing that qmail is non-free are a different group than those > that have anything to do with funding anything. If you can't adequately > maintain the package, say so instead of finding random third parties to > explode at. Being unable to maintain qmail strikes me as a good thing, > frankly, and nothing to be ashamed of. Actually, to be exactly precise, it was a board decision to remove the qmail users from Debian's default passwd file. I worked with Wichert Akkerman on removing these users, and he is the one who told me the decision came from the board, which funds Debian. I'm not just making this stuff up ... Don't take my word for it, ask Wichert. Also read: http://lists.debian.org/debian-devel/1999/11/msg01176.html http://packages.debian.org/changelogs/pool/main/b/base-passwd/base-passwd_3.4.1/changelog Again, I can't force them to add the users back in, and I most definitely can't fix everyone's system. The compromise made YEARS ago was to add a script that will add the users when the qmail-src package is installed to save the user the trouble of doing it themselves. The way qmail works in Debian is a hack. It's ugly, and it's not the most graceful thing, but it works. You both seem like smart guys, and I'm sure you can figure out how to add a user. I'm not the one who wrote qmail such that it requires specific users to be present before you build, hardcoding the uid/gid's into the compiled package, that was DJB. If you install qmail-src, or manually add the users, the package builds fine. If you don't like it, feel free to take it up with DJB, or mark the bug as sent-upstream. From my experience with DJB, you have a snowball's chance in hell at getting as much as an email back from him ... good luck! Debian and Qmail had a rather ugly parting of ways early on in the life of the distribution. At one point in time, all of the official Debian mailsevers were Qmail servers. After the unfortunate ugliness (which was before my time) qmail ended up the non-free red-headed bastard stepchild it is today. It languished for a while, and I ended up taking over the package for Phil Hands and got 1.03 hacked in. I have made 40 releases of qmail since I started managing the package, and take it quite seriously. Your childish comments at the end there made me chuckle. It's very typical of Debian package maintainers, and the #1 reason I stopped reading -private years ago. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402331: Agree with Steve Langasek's analysis.
Quoting Alex Owen <[EMAIL PROTECTED]>: > As others have said there is no need to compile the source when > building a "source as binary" package. Hence there is no need to have > depandancies on specific users when building the qmail-src deb from > the qmail source deb. > > There are two ways of solving this... > [1] the same way as pine by only having a source deb in the archive. > (The difference here is that we would need to build depend on a > trivial package which adds the required users in it's postinst) > > [2] (and more like the package presently tries) the same way as kernel > module packages. > Here we tar up a debianised source tree into a binary deb with a > postinst that adds the required users. For insperation look at some > kernel module source packages... eg: qla2x00 from sarge. From memory a > different debian/rules is copied into the debianised source tree > which ends up in the "binary" than exists in the "source". > > Currently the issue seems to be that the qmail source deb really wants > to build the qmail deb directly and the qmail-src debv seems to have > been hacked in to debian/rules. It also seems that the SAME > debian/rules is used BOTH the qmail-src deb and the qmail deb. This > is in my opinion asking for trouble. See earlier comment about looking > a kernel-module source packages for insparation. > > I hope this analysis helps!?! > Alex Owen I worked up a possible fix for the problem, and sent it to Steve, but he hasn't tried it yet. I don't have a system that replicates the behavior, so it always works for me. I believe I found the offending single line of code, and made an updated package. It looks like you're analysis was spot-on. The debian/rules file would build the qmail package in tandem with the -src package. A one-line fix in the debain/rules file makes that unwanted behavior stop. If I don't hear back from Steve in a day or two, I'll just upload it and he can re-open the bug if it isn't fixed. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351394: All debconf stuff can probably be cleaned from the qmail package
Quoting Christian Perrier <[EMAIL PROTECTED]>: > "Oh no, not him again", says Jon...:-) > > Actually, this contribution is less invasive and controversial than > the former we had to deal with, I think. > > With the removal of debconf stuff, I think that #351394 can be closed > as it becomes obviously useless to switch to po-debconf for templates. > > This means that debian/qmail.templates and debian/qmail.config can be > removed from the package. Some references to debconf perl modules can > also probably be removed from the maintainer scripts and, finally, the > dependencies and build dependencies on debconf can be removed as well. > > (BTW, having Build-Depends for the qmail-src binary package sounds > weird to me). > > Attached is a patch. That patch should close the following bug > reports: > > #351394, #330785, #331009 Well, at least you didn't file another horribly offensive mass-bug. 351394 is a bug reported against the qmail package, which isn't part of the standard distribution. 330785 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296309: ITP: qmail-ldap-src - Qmail 1.03 with LDAP patch
Package: wnpp Severity: wishlist I currently maintain the qmail-src package. I would like to fork qmail-src into qmail-ldap-src as a separate package to handle Debian users who wish to use the qmail-ldap patch from André Oppermann <[EMAIL PROTECTED]> I have had several users ask for a version of qmail that works well with the LDAP patch. I think the best way to accomplish this is through a separate package. --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296308: ITP: qmail-ldap-src - Qmail 1.03 with LDAP patch
Package: wnppp Severity: wishlist I currently maintain the qmail-src package. I would like to fork qmail-src into qmail-ldap-src as a separate package to handle Debian users who wish to use the qmail-ldap patch from André Oppermann <[EMAIL PROTECTED]> I have had several users ask for a version of qmail that works well with the LDAP patch. I think the best way to accomplish this is through a separate package. --- This mail sent through Click2E-Mail http://www.click2e-mail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410125: ucspi-tcp: rblsmtpd queries eight-year-dead RBL by default
Quoting Nick Leverton <[EMAIL PROTECTED]>: Package: ucspi-tcp Version: 0.88-9 Severity: important Tags: patch I rate this bug as Important, but if Paul does set a wildcard on maps.vix.com as discussed then it could quickly escalate. -- If we don't, some Debian users could lose email when Paul runs out of other options, as I expect he will do quite soon. After the last couple of years, you won't catch me publishing an RBL under a domain I still want to use myself :-/ Thanks for the excellent bug report and patch. I have uploaded -13 to the main archive, which includes your patch, and some other miscellaneous cleanup I've been waiting to complete. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > user debian-i18n@lists.debian.org > usertag 388952 + no-cooperation > thanks > > > > I could argue my case with you, but I see no point in it. If you have gone > > through all the trouble to do a massive bug posting against most likely > > countless hundreds of packages, you will stand your ground and refuse to > > capitulate no matter how sound my logic, or articulate my debate. > > Why are you assuming that at least I won't listen to your arguments? > Why do I assume so much? As a direct result of your actions. All you do is keep whining that I have not capitulated to your demands without so much as a reason why. I gave you my reason. I disagree with you, and that is all. > > If this holy jihad continues, I will seek other remedies as afforded by the > > Debian social contract. > > I'm afraid that *you* are insulting. Or at least, you want to be > insulting. > > Unfortunately, it seems that your deep ignorance of the exact > meaning of the word "jihad" in the muslim culture prevents you from > understanding that I should feel honored by this word. So, indeed, > thank you for using it...this is really appreciated. I see what you're trying to do, and I won't take the race bait. Your inner struggle is exactly that ... A struggle with yourself. Get down off your high horse, and think about what you're doing before you do it. Waging war on the rest of the Debian community is not the way to fix a distribution that is already in horrible dis-repair. It is people like you that keep Debian the laughing stock of the open source community. > I would indeed be really glad to see what would happen if you choose > "the other remedies offered by the Social Contract"...but, dear, I'm > afraid I already know the result and I don't really like when fellow > developers feel ridiculous. I'm sure you understand that feeling quite well. Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: Processed: There has to be an explanation for closing bugs
Quoting Manoj Srivastava <[EMAIL PROTECTED]>: > On Tue, 26 Sep 2006 16:02:29 -0500, Jon Marler <[EMAIL PROTECTED]> said: > > > This bug is being closed as it is not a bug. It was a request from > > a translator to make a change that I disagree with. As the package > > maintainer, I am allowed to make that decision. > > While the person filing the bug may have been a translator, > this was discussed on -devel, and a broad concensus reached. This is > not a one off request, there is a nascent policy that debconf notes > are only meant for critical information all installer must see. Low > priority notes vioalte that. > > > This constant harassment over this bug is becoming quite annoying. > > Then just fix your bloody package, man. I did not see a vote on any policy changes. Policy changes require a vote, and I don't remember any vote. You have not addressed any of the concerns in my last email, most notably the fact that I contend this violates section 4 of the social contract. I'm not "fixing the bloody package, man" as I do not see it as broken. Don't you people have anything better to do than harass me over something as trivial as the severity of a message in a debconf file? I mean ... honestly ... Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > First of all, thank you, Jon, for giving me more input on the > background of your reaction to this bug report. > > I was actually not asking for more and I regret that we went in this > long argument. > > Please also note that this mail has been initially written before > Manoj and Joey mails yesterday. I delayed it because it was not > completely finished. > > I still want to send it in the hope that you'll read it. I personnally > consider that we made progress in the dialog, from my POV. > > > The mere act of a mass bug-filing is in effect the first volley in a war > against > > the developers affected. I hate these mass bug filings over something as > > trivial as the severity of a message. > > Some people consider this trivial. Some others don't. Long time ago, > when debconf was introduced and several maintainers jumped on it for > this and that, many users have been complaining about Debian installs > being constantly interrupted by long and verbose notes and questions. > > Only a very long and patient work hand in hand with maintainers has > helped improving this and some mass bug filings have been involved. > > > > > > These messages are marked low because they are low priority. They > > should not be seen by power users, but should be seen by someone who > > wants to know every little thing. > > > > This is why I am annoyed ... > > That reasoning is perfectly understandable and this is indeed an > opinion that some developers share. The majority, however, does not > share this opinion and tend to think that notes to users should not be > displayed during package installs and do more pertain to documentation > like README.Debian. > > Most part of your reaction seems to come from a bad timing in > suggestions you received for your package (first switch to debconf, > then switch to po-debconf to allow translationsthen finally some > jerk suggesting you that your debconf stuff is useless...:-)) > > I may understand that and we should take this as the infortunate part > of a MBF: sometimes we just come at the wrong moment. Point taken, > definitely. > > However, no MBF is indeed requesting that the issue is ugently > fixed. In that specific case, we already know that this is a long-term > work and that every maintainer will handle this at his|her own > paceand, even, take time to discuss with the bug reporter about > the issue and bring more context. > > > Now I get a bug from you complaining that the severity of my messages is > too > > low, forcing you to do more translation work, when it was someone in the > user > > base that specifically asked me to enable such a thing. > > Actually, the "someone" (Thomas) who sent the "switch to po-debconf" > suggestion could perfecly have been the same "someone" who sends you > the "please remove notes" bug report. > > Thomas does a regular survey of packages using debconf and not > po-debconf and systematically reports this to their maintainers (the > requirement for po-debconf should become a requirement for etch+1, > thus making the issue RC). He usually does not always look closer > inside the package code to detect whether the use of debconf fits > "philosophy" of the protocol (in short, not abusing notes). > > > > > > It's this constant power struggle within Debian of "enforcing standards" > over > > this little thing, that little thing, and everything in-between that slows > down > > our release cycle, and brings attention away from real issues like bugs > that > > -*actually*- affect the usability of the system. Spending time rewriting > > Well, this is part of the package maintenance. No packaging is perfect > and we all slowly improve it by learning this or that specific part we > were previously ignoring or misunderstanding. > > > > debconf rules because someone decided that they don't like low priority > note > > messages, is in my opinion, a waste of time. Those messages are low for a > > specific reason: so they can be ignored. If I wanted everyone to have to > read > > them over and over again, I would have marked them with a higher priority. > I > > What I'm explaining you in this bug report is that using a low > priority mostly makes the messages invisible to your package > users...which is also a waste of your time because you certainly took > great care writing them...:-). Hence the suggestion to move this in a > more convenient place. > > I also point, in the BR, that the debconf protocol will quite probably > ignore the "note" type in the future (please get in touch with Joey > Hess to get confirmation of this). This would make these notes > completely invisible and I'm afraid that the wasted time would be even > greater. > > > There aren't that many messages in qmail-src, and if I remember correctly, > the > > number is less than five. You have spent more time and energy arguing with > me > > pointlessly over this crap than it would have taken to translate the > miniscule
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > > > Well .. if notes are going away, that's something entirely different. > > > > I looked at the .config file in question, and I have three notes. > > > > I have a warning message that is marked as high, a message that tells the > user > > how to actually build the package, which is medium, and I check for the > > presence of another essential package and display a warning if it is > missing. > > qmail-src/build could either be considered important enough to have > its priority raised to high...or could maybe move to README.Debian. > > Considering that users who install qmail-src probably already know > that they will have to do something special to get the qmail binary, > I'd probably suggest moving that one to README.Debian > > The same probably goes for the qmail-src/warning for about the same > reasons. > > qmail-src/ucspitcp could be considered an "error" and thus use the > "error" template type. Such "error" templates are recommended to be > used in situation where a previous check verifies whether some > conditions are fulfilled or not. > > > > > > The reason it was coded that way, was that I read this in the packaging > manual > > at http://www.debian.org/doc/packaging-manuals/debconf_specification.html: > > > > "note This template is a note that can be displayed to the user. As > opposed to > > text, it is something important, that the user really should see. If it is > not > > possible to display it, it might be saved to a log file or mailbox for them > to > > see later." > > In the discussion that lead to the mass bug filing, Joey Hess > mentioned that this has been abandoned (at least partlyIIRC > debconf only mails "critical" notes, or so...better ask Joey directly. > > > This tells me that note is exactly what I want to use to display info to > the > > user. This is the entire reason I implemented debconf in the first place, > was > > to display messages to the users. If that is not going to be possible > anymore, > > I will have to switch back to dumping the messages to the console. > > > > If I don't include the message that you have to take an additional step to > > actually build a binary qmail package, most users won't figure it out, > don't > > know where the readme files, and will simply get frustrated and either > complain > > about it or file a bug. > > Well, your package description is saying: "Source only package > for building qmail binary package". > > From my POV, it makes very clear that installing this package will > *not* give you a working qmail but you'll have to do some other > actions to have it running properly (namely compile it). > > It is my understanding that users who will install this package will > be some kind of power users...at least powered enough to go looking in > /usr/share/doc/qmail-src > > > I could change the type to text, which will have no effect on the end users > > experience, but would remove the evil note. I just need to force the user > to > > see the message, and click OK. I don't really care if it's a note, text, > > whatever. I just need them to see it, and acknowledge it. That's all. > > > "error" type could be considered appropriate as an alternative to > README.Debian even if we're not exactly speaking about an "error" > > > I can't promise that noone will criticize this later, > thoughprobably with the rationale that wanting to display this > information in all cases could be considered as too strong. > > > Unfortunately, you're giving the users far too much credit. I have had to deal with bug reports for issues far more trivial than that. I do, however, run into some bright people every now and then. I'll just go ahead and just remove all the debconf prompts all-together, I'm sick of having to argue about it. If people get pissed off about it, I will direct them to you. Expect a new qmail-src shortly. Will that end this once and for all? Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#601240: Patch for the 1.03-49.3 NMU of qmail
Thanks Christian! I've been having trouble with my mail server lately and didn't get your email on the 26th. Thank you for sorting this out for me. I really appreciate it. Cheers! Jon > Dear maintainer of qmail, > > On Thursday, January 26, 2012 I sent you a notice announcing my intent to > upload a > NMU of your package to fix its pending l10n issues, after an initial > notice sent on Saturday, January 21, 2012. > > You either agreed for this NMU or did not respond to my notices. > > I will now upload this NMU to DELAYED/7-DAY. > > The NMU patch is attached to this mail. > > The NMU changelog is: > > > Source: qmail > Version: 1.03-49.3 > Distribution: unstable > Urgency: low > Maintainer: Christian Perrier > Date: Sat, 04 Feb 2012 08:37:00 +0100 > Closes: 601240 601471 624721 624860 > Changes: > qmail (1.03-49.3) unstable; urgency=low > . > * Non-maintainer upload. > * Fix pending l10n issues. Debconf translations: > - Japanese (Hideki Yamane). Closes: #601240, #601471, #624721 > - Dutch; (Jeroen Schot). Closes: #624860 >
Bug#469183: qmail-src: qmail in the public domain
On Mar 3, 2008, at 11:15 AM, Luke Schierer wrote: As qmail is now in the public domain, it should be possible to build a binary-package of qmail and move it out of non-free. It would be nice to see this happen. Please look at old bug reports before reporting new bugs, as this bug has been opened several times. There is a binary qmail package coming. Gerritt Pape will be submitting and maintaing that package(s). qmail-src will stay around for those who like to "roll their own" and to satisfy those who prefer the status-quo. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466074: qmail is free : what about a binary package now ?
Please see bug #457318. Cheers! Jon On Nov 6, 2008, at 11:45 PM, Greg Price wrote: Now that the author of this software has seen the light and made it free software, it'd be great to have it in Debian. Is there a particular obstacle known to be in the way of doing so, or is just a matter of someone doing the work? Thanks, Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#548788: qmail: not packaged in debian, despite being released into the public domain some time ago
I requested a merge of this bug with #457318 Gerrit Pape filed an ITP for qmail in Dec. of 2007. There is an ongoing debate on how to handle qmail, and I suggest you look through the maillist archives or the ITP bug report for more information. Also, Gerritj has an excellent binary package of qmail that he distributes on his website at http://smarden.org/pape/Debian/ I highly recommend his work. Cheers! Jon On Sep 28, 2009, at 2:39 PM, dave bl wrote: Package: qmail Version: 1.03 Severity: wishlist qmail is not in debian main. there is a qmail-source package in contrib. however,qmail 1.03 was released into the public domain as per http://cr.yp.to/qmail/dist.html . Thank you -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548788: qmail: not packaged in debian, despite being released into the public domain some time ago
Please go and read the material. You will see that even though the ITP bug was opened in 2007, the debate continues. There have been some very recent comments on both the ITP bug, and the mail list. Sometimes the process takes time, and the process is just taking a while in this case. There are a lot of really smart people involved, and a lot of factors to consider. I would also invite you to join the deliberative process, and make your voice heard as a user of Debian. We are an open community and will welcome the fresh point of view. The bug I linked you to is an ITP bug. That stands for "Intend To Package." So, to answer your question, yes. Gerrit intends to package qmail. The first step in that process is an ITP bug agains wnpp. Gerrit has already packaged qmail, which is available on his website, but not in the official Debian archive. Gerrit is a well accomplished Debian Maintainer that is already taking care of packages in Debian, and as soon as his ITP is approved, will have a qmail binary package ready for upload into the archive. I have worked with Gerrit in the past, and he is very easy to work with, and very accommodating. If the ITP ends up not approved, we will stay with the current source- only package. Either way, the proper process is already being followed, hence the closing of this bug. Cheers! Jon On Sep 28, 2009, at 7:36 PM, db wrote: Ok. I am confused. The previous bug from 2007, was regarding qmail-source not qmail. It also was not touched for some time now. Hence, i filed this bug. Sure by all means close this bug. However, you should note that this was a wishlist report and not a bug report, as such Does Gerrit intend to package qmail ? 2009/9/29 Jon Marler : Well, the merge attempt was an epic fail. I'm going to go ahead and close this. Gerrit is getting this all sorted out, and with any luck, we will have a resolution soon. I'm trying to stay out of it and let the process work it's way through. Cheers! Jon On Sep 28, 2009, at 2:39 PM, dave bl wrote: Package: qmail Version: 1.03 Severity: wishlist qmail is not in debian main. there is a qmail-source package in contrib. however,qmail 1.03 was released into the public domain as per http://cr.yp.to/qmail/dist.html . Thank you -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#143098: Please add TLS support in qmail !
Thanks for the suggestion. Adding TLS support would basically require every user to setup certs just to get a base qmail system up and running. This would also mean breaking existing configurations. May users are using other mechanisms, such as stunnel, to provide SSL and/or TLS encryption. Just slamming TLS in would likely cause these systems to break as well, or at a bare minimum, require considerable planning ahead to move certs around and adjust listening ports. I appreciate the bug report, but I am going to mark this as wishlist. Considering the enormous impact this patch would have, I'm hesitant to just add it to the default package. One of the things that I have in-place in the build-qmail script is the ability to add your own patches before building. I would invite you to add this patch when building qmail on your own systems. Cheers! Jon On Aug 26, 2009, at 10:16 AM, Thomas de Grivel wrote: Hi Jon, Thanks for maintaining qmail-src package. However I think many more people would use your great package if it included the TLS patch which is needed to secure connections with qmail-smtp. It is very regrettable to see this package not fully functional in production setups on such an insecure network such as the internet. Please let me know if you can handle this shortly, I will be glad to help. Regards, -- Thomas LowH.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#485956: FTBFS: uses chown inappropriately
If you use fakeroot to call dpkg-buildpackage, it works prefectly. Something is wrong with the way that dpkg-buildpackage is calling fakeroot. The chown calls work perfect, and you can build the package using a different syntax. Not sure what you need done here. Jon On Jun 12, 2008, at 10:47 AM, Dominic Hargreaves wrote: Package: qmail Version: 1.03-45 Severity: serious Justification: fails to build from source On both etch and sid systems apt-get source qmail cd qmail... dpkg-buildpackage -rfakeroot -uc -us results in: # Install debconf files #cp debian/qmail-src.config debian/tmp-src/DEBIAN/config #cp debian/qmail-src.templates debian/tmp-src/DEBIAN/templates dpkg-gencontrol -isp -pqmail-src -Pdebian/tmp-src chown -R root.root debian/tmp-src chown: changing ownership of `debian/tmp-src/usr/share/doc/qmail-src/ changelog.D ebian.gz': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc/qmail-src/ copyright': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc/qmail-src/ README.Debi an.gz': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc/qmail- src': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/share/doc': Operation not permi tted chown: changing ownership of `debian/tmp-src/usr/share': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/bin/build-qmail': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/bin': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/src/qmail-src/ qmail_1.03-45.dsc ': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/src/qmail-src/ qmail_1.03.orig.t ar.gz': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/src/qmail-src/ qmail_1.03-45.dif f.gz': Operation not permitted chown: changing ownership of `debian/tmp-src/usr/src/qmail-src': Operation not p ermitted chown: changing ownership of `debian/tmp-src/usr/src': Operation not permitted chown: changing ownership of `debian/tmp-src/usr': Operation not permitted chown: changing ownership of `debian/tmp-src/DEBIAN/control': Operation not perm itted chown: changing ownership of `debian/tmp-src/DEBIAN/prerm': Operation not permit ted chown: changing ownership of `debian/tmp-src/DEBIAN/postinst': Operation not per mitted chown: changing ownership of `debian/tmp-src/DEBIAN/postrm': Operation not permi tted chown: changing ownership of `debian/tmp-src/DEBIAN': Operation not permitted chown: changing ownership of `debian/tmp-src': Operation not permitted make: *** [binary-src] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485956: Errata - resetting severity
severity 485956 minor thanks Actually, I disagree. This is not a serious bug, and will build with the standard Debian tools, including the autobuilder. It doesn't work using the command you have chosen for it, but there is nowhere in the policy you referred to that states that specific command must be supported. I am not closing the bug, but it is not a serious bug. If you disagree further, I suggest you try a remedy other than changing the severity again, as I will simply change it back. Cheers! Jon On Jun 12, 2008, at 6:41 PM, Dominic Hargreaves wrote: severity 485956 serious thanks On Thu, Jun 12, 2008 at 06:09:14PM -0500, Jon Marler wrote: severity 485956 minor Erm, no, this is a FTBFS bug, and deserves the severity I gave it. The package fails to build with standard Debian tools, called in their standard ways, and violates a policy MUST. Please see http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules and my other reply to this bug report. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491916: qmail: Preinst fails if /etc/inetd.conf does not exist
On Aug 13, 2008, at 4:41 PM, Moritz Muehlenhoff wrote: Jon Marler wrote: All of that inetd.conf stuff is old legacy code from a migration long long ago before update-inetd was available. I believe I will just remove it all together as it is no longer necessary, and probably never was in the first place. I have a release that I am preparing to clean out some other bugs, and will get this in there. Hi Jon, what's the status? Lenny release is getting closer... Cheers, Moritz It's coming. I don't have much free time, and my test machine recently died. I should have it out in the next week or so. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485956: FTBFS: uses chown inappropriately
On Jun 15, 2008, at 4:23 AM, Raphael Hertzog wrote: On Thu, 12 Jun 2008, Jon Marler wrote: If you use fakeroot to call dpkg-buildpackage, it works prefectly. Something is wrong with the way that dpkg-buildpackage is calling fakeroot. The chown calls work perfect, and you can build the package using a different syntax. There's nothing wrong in dpkg-buildpackage. The "build" target is called _without_ root rights. Only the clean and binary target are supposed to have root rights. However your build target depends on binary-src and binary-src contains the call "chown -R root.root $(TMPSRC)". You should arrange your build system to have the operations that require root to be called when debian/rules binary is called and not when debian/rules build is called. I've been digging around in this, and have found something extremely peculiar. This odd behavior only appears when trying to build release -45, but not -44. As far as I can tell, the differences between the two are very minor. I can't figure out what broke between -44 and -45 that has caused dpkg-buildpackage to fail. The rules file is the same in both releases, yet one builds and the other fails. Do you have any ideas why that might be? This bug is the last bug holding me back from uploading a new qmail- src for lenny. Any help you could provide would be appreciated. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491916: qmail: Preinst fails if /etc/inetd.conf does not exist
Thanks for the report. All of that inetd.conf stuff is old legacy code from a migration long long ago before update-inetd was available. I believe I will just remove it all together as it is no longer necessary, and probably never was in the first place. I have a release that I am preparing to clean out some other bugs, and will get this in there. Cheers! Jon On Jul 22, 2008, at 1:30 PM, Dominic Hargreaves wrote: Package: qmail Version: 1.03-45 Severity: important On a minimal system with no /etc/inetd.conf, qmail installation fails: callisto:/usr/share/doc/qmail-src# dpkg -i /tmp/qmail/ qmail_1.03-45_i386.deb (Reading database ... 60331 files and directories currently installed.) Unpacking qmail (from .../qmail/qmail_1.03-45_i386.deb) ... Performing install First installation of the Debian qmail package... Checking if qmail is already installed on this computer... no. Checking group qmail (gid 64010)... ok. Checking user alias (uid 64010, gid 65534, homedir /var/qmail/ alias)... ok. Checking user qmaild (uid 64011, gid 65534, homedir /var/qmail)... ok. Checking user qmails (uid 64012, gid 64010, homedir /var/qmail)... ok. Checking user qmailr (uid 64013, gid 64010, homedir /var/qmail)... ok. Checking user qmailq (uid 64014, gid 64010, homedir /var/qmail)... ok. Checking user qmaill (uid 64015, gid 65534, homedir /var/qmail)... ok. Checking user qmailp (uid 64016, gid 65534, homedir /var/qmail)... ok. Could not open /etc/inetd.conf dpkg: error processing /tmp/qmail/qmail_1.03-45_i386.deb (--install): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: /tmp/qmail/qmail_1.03-45_i386.deb Suggested fix: use update-inetd. Preferably do all this in postinst rather than preinst, then just Depend on update-inetd. Failing that, Pre-Depend on inetd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491919: qmail-src: Prompts should use debconf
Let's please not re-open that debacle. I was informed that Debconf was specifically -*not*- to be used to preset information to users, and had one of those spray-and-pray bugs filed against the package. I ripped all of it out because there was no other solution. You can't show it in debconf, and you can't show it in the terminal. Those messages are there strictly for informative purposes, and would violate policy if moved to debconf. If you feel that strongly that they shouldn't be there, they will have to be removed entirely. They only provide helpful guidance to an admin that may be accidentally attempting to remove qmail. I will remove them in true Debian fashion if you don't see their value, or believe that their presence violates the rules. Cheers! Jon On Jul 22, 2008, at 2:09 PM, Dominic Hargreaves wrote: Package: qmail-src Version: 1.03-45 Severity: important Policy 3.9.1 suggests that user prompting should be done via debconf, not directly to the terminal. qmail's prerm (at least) prompts directly to the terminal, thus presenting an unfamiliar interface to users. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466447: qmail-local maildir delivery race condition
No problem.
I am working on a new release to fix the outstanding RC bugs, and will
get this fix in as well.
I am going to back out that link-sync patch. It's more trouble than
it's worth.
Cheers!
Jon
On Jul 28, 2008, at 3:18 PM, Pablo 'merKur' Kohan wrote:
I just started getting MANY complaints about duplicate e-mail
delivery
from IMAP users. Upon investigation, it turns out that Dan Bernstein
doesn't obey his own rules about manipulating Maildirs.
I'm having the same issues one of my servers.
Thanks for diagnosing it ! It drove my users crazy.
One comment though. While checking this, I found out that it's not in
the original qmail source, but it comes from one of the applied
patches:
Frank Denis's qmail-link-sync
http://www.thedjbway.org/qmail/patches/qmail-1.03.link-sync.patch
Alternatively, you can just ignore a failure to open. I.e. replace
if ((fd = open(fnnewtph, O_RDONLY)) < 0 ||
fsync(fd) < 0 || close(fd) < 0) goto fail;
by
if ((fd = open(fnnewtph, O_RDONLY)) >= 0)
{
fsync(fd);
close(fd);
}
This works very well, and is much less intrusive than Guenter's
syncdir
patch (which actually fsyncs the directory, as you mentioned).
Jon, could you please include the fix above in future qmail-src
releases ?
Thanks,
Pablo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485956: found 485956 in qmail/1.03-46
On Sep 13, 2008, at 10:03 AM, Marc 'HE' Brockschmidt wrote: # Automatically generated email from bts, devscripts version 2.10.28 #patch didnt touch debian/rules found 485956 qmail/1.03-46 Fixed in -47 Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498869: ucspi-tcp-src: FTBFS
On Sep 13, 2008, at 5:45 PM, Carsten Hey wrote: Package: ucspi-tcp-src Severity: grave Hi, while checking whether bug #174353 "build-ucspi-tcp fails on libc6 2.3.1-7" is still present and if it is release critical - more precisely, before I had the chance to do so, I tried to build ucspi-tcp-src using debuild -rfakeroot which failed. Since ucspi-tcp is now available in main, maintained by Gerrit Pape, do you think ucspi-tcp-src is still useful in Debian? I see two options: a) Remove ucspi-tcp-src from Debian. b) Fix this bug, then check if #174353 is still present, if it is, upgrade its severity to grave and fix this too. Users could decide oneself whether they want a precompiled package or your package which they might use since ages. I have been so far unable to reproduce 174353. I may flag it as unreproducible, and see if the anyone has the same issue before I spend a whole bunch of time on it. Gerrit and I have discussed the two packages, and have come up with a way for them to live together in harmony. Thanks for the bug report. I have uploaded -15 to the repository, and will request a freeze exception. Cheers! Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326415: Processed: Erk
I am confused as to what you expect me to do here.
There are no TCP listeners in Qmail. There are in ucspi-tcp, which does support
IPV6, and does work w/ Qmail. Qmail does support IPV6, when used with a TCP
listener that does support IPV6. Ucspi-tcp is not the only TCP listener you
can use with Qmail, and there is nothing in Qmail that prevents IPV6 from
working.
Why have you reopened this bug?
Cheers!
Jon
On Mar 23, 2010, at 6:15 PM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> reopen 326415
> Bug #326415 {Done: Jon Marler } [qmail-src] Please
> support IPv6 or Advertise lack
>> stop
> Stopping processing here.
>
> Please contact me if you need assistance.
>
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#326415: closed by Jon Marler (No TCP listeners in qmail)
Have you tested that this patch works? I don't have an IPV6 network to play with. Cheers! Jon On Mar 23, 2010, at 6:11 PM, Elliott Mitchell wrote: > reopen 326415 > stop > >> From: ow...@bugs.debian.org (Debian Bug Tracking System) >> There are no TCP listeners in the qmail package. The TCP layer is handled >> by another package. I would be more than happy to add IPV6, but since it >> doesn't have any TCP listeners, it is not possible. >> > > Please point to where TCP listeners were mentioned in the original bug > report (hint, there isn't any such mention). > > Listening on an interface isn't the only place where IPv6 support is > needed. qmail does reverse lookups on incoming connections and does > forward lookups when sending mail, both of these places in *qmail* need > IPv6 awareness. > > > Seeing how the original link is no longer valid (I'll contact the > author), I'm attaching a copy of the patch. > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) / > \_CS\ | _ -O #include O- _ | / _/ > 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576640: update request for qmail-src
>Hello Jon, > >Have you been able to sort things out? > >if the FTBFS is #584745, I think the report is too incomplete for >being properly processed. The bug submitter never followed up, >also. I'd suggest tagging "moreinfo" and ignoring ATM. It's a valid bug. It is super easy to reproduce ... just try "apt-get source -b qmail-src" and you can easily see where it blows up. I have found the regression, and am still trying to sort out how to get back to a working state, and then merge back in the changes that I have made since the regression. I have been hesitant to submit what I have done without making sure I'm not producing yet another regression. I just haven't had much time to work on it. I'll get it done this week though. I understand your urgency in wanting to get this patch finished, and I will be sensitive to that urgency. Cheers! Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
