From eliswilson at hushmail.com Wed May 1 00:21:06 2013 From: eliswilson at hushmail.com (eliswilson at hushmail.com) Date: Tue, 30 Apr 2013 18:21:06 -0400 Subject: Biggest Fake Conference in Computer Science Message-ID: <20130430222107.346CF14DBE1@smtp.hushmail.com> Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world?s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP?s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP?s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia?s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP?13 because of the fears of their image being tarnished due to WORLDCOMP?s fraudulent activities. That is why WORLDCOMP?13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP?s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet?s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From hpeter at agitator.com Mon May 6 10:32:44 2013 From: hpeter at agitator.com (Peter Holzer) Date: Mon, 06 May 2013 08:32:44 -0000 Subject: [Bug 1176793] [NEW] memory consumption References: <20130506083244.15054.38526.malonedeb@soybean.canonical.com> Message-ID: <20130506083244.15054.38526.malonedeb@soybean.canonical.com> Public bug reported: Hi I'm running the 2.5K mailman list with postfix on a Ubuntu 12.04.2 LTS with about 500MB of memory. Lately I was checking munin about the health of that machine and was a little surprised to see that it's running heavily into swap. After a reboot of the machine it continously starts to use more and more memory/swap and tops after about two weeks - two weeks where no newsletter was sent out to the list. I attached two sets of munin graphs and screenshots of the top command. In the first munin shot the first small drop is when i stopped postorios, the second big drop is when i stopped mailman. After a few hours i started mailman again and it started to eat up memory again and after about 5 days it's already using 3 quarters of the max. Did anyone see similar behavior? The machine is rather small, but shouldn't that be enough to run a list? What minimal resources would you recommend? What else can/should I check to give more insight into this issue? Peter ** Affects: mailman Importance: Undecided Status: New ** Attachment added: "munin screenshots" https://bugs.launchpad.net/bugs/1176793/+attachment/3666507/+files/Archive.zip -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1176793 Title: memory consumption To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1176793/+subscriptions From varunsharmalive at gmail.com Wed May 15 19:53:27 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Wed, 15 May 2013 17:53:27 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius Message-ID: <20130515175326.28892.63473.launchpad@ackee.canonical.com> Varun Sharma has proposed merging lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 Added delete user functionaly, created user_delete method to postorius/views/user.py and added template user_confirm_delete.html to templates. Right now users can be deleted by superuser only but as discussed on irc, self deletion of user may be added in future. -- https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is requested to review the proposed merge of lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 9497 bytes Desc: not available URL: From flo.fuchs at gmail.com Thu May 16 17:24:27 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Thu, 16 May 2013 15:24:27 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius In-Reply-To: <20130515175326.28892.63473.launchpad@ackee.canonical.com> Message-ID: <20130516152427.8802.33190.launchpad@ackee.canonical.com> The proposal to merge lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius has been updated. Status: Needs review => Work in progress For more details, see: https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 -- https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is subscribed to branch lp:postorius. From flo.fuchs at gmail.com Thu May 16 17:22:34 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Thu, 16 May 2013 15:22:34 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius In-Reply-To: <20130515175326.28892.63473.launchpad@ackee.canonical.com> Message-ID: <20130516152143.7496.67669.codereview@wampee.canonical.com> Review: Needs Fixing Thanks Varun Sharma for taking on this feature! Deleting users works fine, there are only a couple of minor things: 1) display_name in the success message The display_name is not a mandatory field, so we cannot assume it is set. If it isn't the success message will say: "The user None has been deleted". I suggest to use the email address for the success message as a fallback. 2) Mailman not running (MailmanAPIError) I like that you put the logic inside a try/except block, but there's one important scenario currently missing: It's possible that Postorius running but Mailman is not, in which case the REST API wouldn't respond and no HTTPError would be raised (resulting in an ugly 500 error raised by Django). mailman.client has an Exception class for that (MailmanAPIError) which we use to render a generic "API not available message". See an example in the user_new function. Could you add that as well? 3) Tests The test coverage in Postorius is far from complete, but I'd like to add a test for every new feature. Would you like to take a shot at that? Although I have to acknowledge that testing the Postorius/mailman.client/Mailman combination can be a little tricky, so I can also just do it before I do the merge. 4) This branch It looks like this branch not only contains the user deletion feature, but also changes on the preferences template. Usually we'd like to merge branches feature by feature. So could you add the user deletion changes to a fresh feature branch? Cheers and thank you very much Florian -- https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is subscribed to branch lp:postorius. From stephen at xemacs.org Thu May 16 17:59:26 2013 From: stephen at xemacs.org (Stephen Turnbull) Date: Thu, 16 May 2013 15:59:26 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius In-Reply-To: <20130515175326.28892.63473.launchpad@ackee.canonical.com> Message-ID: <20130516155900.7307.83580.codereview@wampee.canonical.com> Varun, 1. In an earlier revision of user_delete(), you had the code user_id = kwargs["user_id"] user = MailmanUser.objects.get(address=user_id) outside the "if". I don't understand why you moved it inside, and moving the assignment to user_id inside the "try" seems inappropriate since you have to do it again after the "if" if the request isn't a POST. This is a minor DRY violation. 2. The redirect to "user_index" is also repeated (once in the try, once in the except). I think this can go outside the try, no? 3. What is going to throw an HTTPError inside the try? Surely the assignment to user_id won't throw an HTTPError. So you should restrict the scope of the try to those statements that can actually raise the error you're catching. That's only user.delete(), right? I think the same argument applies to catching MailmanAPIError. However, Florian seems to be OK with it, so it's really a matter of style. A possible alternative would be to attack the DRY violation at the root, by writing a decorator that catches those two errors. This would be useful because the same pattern appears in other commands like user_new(). -- https://code.launchpad.net/~sharmavarun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is subscribed to branch lp:postorius. From varunsharmalive at gmail.com Fri May 17 20:19:38 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Fri, 17 May 2013 18:19:38 -0000 Subject: [Merge] lp:~varun/postorius/postorius_gsoc2013_modified into lp:postorius Message-ID: <20130517181937.12559.68416.launchpad@ackee.canonical.com> Varun Sharma has proposed merging lp:~varun/postorius/postorius_gsoc2013_modified into lp:postorius. Requested reviews: Florian Fuchs (flo-fuchs) For more details, see: https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164480 Added deletion of user functionality for superusers. Added view user_delete to views/user.py and template user_confirm_delete.html to templates/users. As per the suggestions from florian and steve, i have improved few things from my last merge request like handling of MailmanApiError and showing email id in notification rather than display name which was not a mandatory field. -- https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164480 Your team Mailman Coders is subscribed to branch lp:postorius. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 3834 bytes Desc: not available URL: From varunsharmalive at gmail.com Fri May 17 20:26:22 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Fri, 17 May 2013 18:26:22 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius In-Reply-To: <20130516152143.7496.67669.codereview@wampee.canonical.com> Message-ID: <20130517182559.7079.12373.codereview@wampee.canonical.com> > Thanks Varun Sharma for taking on this feature! > > Deleting users works fine, there are only a couple of minor things: > > 1) display_name in the success message > > The display_name is not a mandatory field, so we cannot assume it is set. If > it isn't the success message will say: "The user None has been deleted". I > suggest to use the email address for the success message as a fallback. > > 2) Mailman not running (MailmanAPIError) > > I like that you put the logic inside a try/except block, but there's one > important scenario currently missing: It's possible that Postorius running but > Mailman is not, in which case the REST API wouldn't respond and no HTTPError > would be raised (resulting in an ugly 500 error raised by Django). > mailman.client has an Exception class for that (MailmanAPIError) which we use > to render a generic "API not available message". See an example in the > user_new function. Could you add that as well? > > 3) Tests > > The test coverage in Postorius is far from complete, but I'd like to add a > test for every new feature. Would you like to take a shot at that? Although I > have to acknowledge that testing the Postorius/mailman.client/Mailman > combination can be a little tricky, so I can also just do it before I do the > merge. > > 4) This branch > > It looks like this branch not only contains the user deletion feature, but > also changes on the preferences template. Usually we'd like to merge branches > feature by feature. So could you add the user deletion changes to a fresh > feature branch? > > Cheers and thank you very much > Florian Thanks Florian for taking time in reviewing and suggesting the improvements. I have taken all of your suggestions in consideration and done all the suggested changes in my new merge request at https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164480 -- https://code.launchpad.net/~varun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is subscribed to branch lp:postorius. From varunsharmalive at gmail.com Fri May 17 20:57:25 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Fri, 17 May 2013 18:57:25 -0000 Subject: [Merge] lp:~varun/postorius/postorius_gsoc2013_modified into lp:postorius Message-ID: <20130517185724.23504.95975.launchpad@ackee.canonical.com> Varun Sharma has proposed merging lp:~varun/postorius/postorius_gsoc2013_modified into lp:postorius. Requested reviews: Florian Fuchs (flo-fuchs) For more details, see: https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164490 Added deletion of user functionality for superusers. Added view user_delete to views/user.py and template user_confirm_delete.html to templates/users. As per the suggestions from florian and steve, i have improved few things from my last merge request like handling of MailmanApiError and showing email id in notification rather than display name which was not a mandatory field. Plus removed extra return redirect statements from try/except blocks. -- https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164490 Your team Mailman Coders is subscribed to branch lp:postorius. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 3870 bytes Desc: not available URL: From varunsharmalive at gmail.com Fri May 17 21:05:27 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Fri, 17 May 2013 19:05:27 -0000 Subject: [Merge] lp:~sharmavarun/postorius/postorius_gsoc2013 into lp:postorius In-Reply-To: <20130516155900.7307.83580.codereview@wampee.canonical.com> Message-ID: <20130517190424.7389.75554.codereview@wampee.canonical.com> > Varun, > > 1. In an earlier revision of user_delete(), you had the code > > user_id = kwargs["user_id"] > user = MailmanUser.objects.get(address=user_id) > > outside the "if". I don't understand why you moved it inside, and moving the > assignment to user_id inside the "try" seems inappropriate since you have to > do it again after the "if" if the request isn't a POST. This is a minor DRY > violation. > > 2. The redirect to "user_index" is also repeated (once in the try, once in the > except). I think this can go outside the try, no? > > 3. What is going to throw an HTTPError inside the try? Surely the assignment > to user_id won't throw an HTTPError. So you should restrict the scope of the > try to those statements that can actually raise the error you're catching. > That's only user.delete(), right? I think the same argument applies to > catching MailmanAPIError. However, Florian seems to be OK with it, so it's > really a matter of style. A possible alternative would be to attack the DRY > violation at the root, by writing a decorator that catches those two errors. > This would be useful because the same pattern appears in other commands like > user_new(). Hi Steve, Thanks for the review. As per your suggestion regarding catching of MailmanAPIError, i have reduced its uncertainty by adding it only to api calls. Also as we discussed on irc, the "if" block is necessary to handle the user deletion request and the code outside the "if" request renders the confirmation template. Both are independent of each other. I moved > user_id = kwargs["user_id"] > user = MailmanUser.objects.get(address=user_id) under the "if" block because the creating of mailman user instance is not required in the case of rendering of template. Also as per your suggestions, i have removed the return redirect statement form try and catch statement which was violating DRY principles and placed a common return statement. My new branch with all the changes is at https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified -- https://code.launchpad.net/~varun/postorius/postorius_gsoc2013/+merge/164011 Your team Mailman Coders is subscribed to branch lp:postorius. From aurelien at bompard.org Sat May 18 12:35:09 2013 From: aurelien at bompard.org (=?utf-8?q?Aur=C3=A9lien_Bompard?=) Date: Sat, 18 May 2013 10:35:09 -0000 Subject: [Bug 1181498] [NEW] subject_prefix is not part of the IMailingList interface References: <20130518103509.15387.12066.malonedeb@chaenomeles.canonical.com> Message-ID: <20130518103509.15387.12066.malonedeb@chaenomeles.canonical.com> Public bug reported: In mailman/interfaces/mailinglist.py, in the IMailingList interface, there's a display_name property whoose documentation reads: "This is used in locations such as the message footers and Subject prefix.". It's actually not true, in the MailingList model class (in mailman/model/mailinglist.py) there's a subject_prefix attribute for this value, and it's the one that Postorius edits. Thus the interface is incomplete (which is not a big problem) and the documentation is misleading (which is a bigger problem IMHO). ** Affects: mailman Importance: Undecided Status: New ** Tags: documentation mailman3 ** Tags added: documentation mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1181498 Title: subject_prefix is not part of the IMailingList interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1181498/+subscriptions From flo.fuchs at gmail.com Tue May 21 14:41:27 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Tue, 21 May 2013 12:41:27 -0000 Subject: [Merge] lp:~varun/postorius/postorius_gsoc2013_modified into lp:postorius In-Reply-To: <20130517185724.23504.95975.launchpad@ackee.canonical.com> Message-ID: <20130521124023.954.11217.codereview@soybean.canonical.com> Review: Needs Fixing Hi Varun, thank you for doing another merge request! I have a couple of small issues, all concerning the ``user_delete`` view (some of them were already mentionend in Stephen Turnbull's comment on your last merge proposal): 1) ``except MailmanAPIError`` covers ``MailmanUser.objects.get`` (like it should), but doesn't cover ``user.delete()``. But it's possible (even if unlikely) that the REST service is running when you retrieve the user object, but isn't any more once you attempt to delete the user. Is the extra nesting necessary? 2) I think you can get rid of one of the two user_id assignments. Actually, I think you can get rid of both: We know from the url definition that this view function should only be called with a user_id argument. So it could be made a mandatory argument, instead of assigning it from **kwargs. If (for some reason) the function will be called *without* the user_id argument, the resulting TypeError is exactly what we want. 3) In an effort to make the try block as simple as possible, the ``messages.success`` call could probably be moved outside. 4) There are some minor PEP8 violations (argument list: no whitespace after ','; email_id assignment: no whitespace around '='). Cheers Florian -- https://code.launchpad.net/~varun/postorius/postorius_gsoc2013_modified/+merge/164490 Your team Mailman Coders is subscribed to branch lp:postorius. From aurelien at bompard.org Sun May 26 18:32:58 2013 From: aurelien at bompard.org (=?utf-8?q?Aur=C3=A9lien_Bompard?=) Date: Sun, 26 May 2013 16:32:58 -0000 Subject: [Bug 1184376] [NEW] REST server crashes on "reopen" References: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Message-ID: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Public bug reported: Mailman's REST server crashes on the "mailman reopen" command. Here are the only lines I get in the logs: May 26 12:29:01 2013 (30830) Master started May 26 12:29:05 2013 (30844) RESTRunner runner started. May 26 12:29:05 2013 (30844) Starting REST server May 26 12:29:05 2013 (30837) DigestRunner runner started. May 26 12:29:05 2013 (30843) RetryRunner runner started. May 26 12:29:05 2013 (30848) CommandRunner runner started. May 26 12:29:05 2013 (30845) BounceRunner runner started. May 26 12:29:05 2013 (30846) LMTPRunner runner started. May 26 12:29:05 2013 (30850) NNTPRunner runner started. May 26 12:29:05 2013 (30838) PipelineRunner runner started. May 26 12:29:06 2013 (30839) ArchiveRunner runner started. May 26 12:29:06 2013 (30849) VirginRunner runner started. May 26 12:29:06 2013 (30836) IncomingRunner runner started. May 26 12:29:06 2013 (30840) OutgoingRunner runner started. May 26 12:29:33 2013 (30830) Master watcher caught SIGHUP. Re-opening log files. May 26 12:29:33 2013 (30848) CommandRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30843) RetryRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30838) PipelineRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30837) DigestRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30839) ArchiveRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30836) IncomingRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30846) LMTPRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30849) VirginRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30845) BounceRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30850) NNTPRunner runner caught SIGHUP. Reopening logs. May 26 12:29:33 2013 (30840) OutgoingRunner runner caught SIGHUP. Reopening logs. As you can see in the "caught SIGHUP" lines, there is nothing about the REST server, and indeed there is no "runner --runner=rest:0:1" process running anymore. I have to restart mailman to get the REST server back online. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1184376 Title: REST server crashes on "reopen" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1184376/+subscriptions From aurelien at bompard.org Sun May 26 18:43:48 2013 From: aurelien at bompard.org (=?utf-8?q?Aur=C3=A9lien_Bompard?=) Date: Sun, 26 May 2013 16:43:48 -0000 Subject: [Bug 1184376] Re: REST server crashes on "reopen" References: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Message-ID: <20130526164349.7272.67451.malone@chaenomeles.canonical.com> After looking at the source code, it seems to come from the fact that the REST runner has the intercept_signals attribute set to False. Any reason for that ? -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1184376 Title: REST server crashes on "reopen" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1184376/+subscriptions From rkw at dataplex.net Mon May 27 14:15:35 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Mon, 27 May 2013 12:15:35 -0000 Subject: [Merge] lp:~wacky/postorius/GSoC2013 into lp:postorius Message-ID: <20130527121532.31109.67620.launchpad@ackee.canonical.com> Richard Wackerbarth has proposed merging lp:~wacky/postorius/GSoC2013 into lp:postorius. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~wacky/postorius/GSoC2013/+merge/165866 Accumulated changes from 2012 that haven't been merged. -- The attached diff has been truncated due to its size. [Moderator's note: The attachment has been completely removed as even after truncation it was way too big. The diff is available at the URL below.] https://code.launchpad.net/~wacky/postorius/GSoC2013/+merge/165866 Your team Mailman Coders is requested to review the proposed merge of lp:~wacky/postorius/GSoC2013 into lp:postorius. From varunsharmalive at gmail.com Tue May 28 08:25:28 2013 From: varunsharmalive at gmail.com (Varun Sharma) Date: Tue, 28 May 2013 06:25:28 -0000 Subject: [Merge] lp:~varun/postorius/user_delete into lp:postorius Message-ID: <20130528062528.13602.71131.launchpad@ackee.canonical.com> Varun Sharma has proposed merging lp:~varun/postorius/user_delete into lp:postorius. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~varun/postorius/user_delete/+merge/165962 The patch will enable the superusers (having django instance variable is_superuser set to True) to delele other users. All the subscriptions of the deleted user will also be deleted. -- https://code.launchpad.net/~varun/postorius/user_delete/+merge/165962 Your team Mailman Coders is requested to review the proposed merge of lp:~varun/postorius/user_delete into lp:postorius. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 3874 bytes Desc: not available URL: From 1184376 at bugs.launchpad.net Tue May 28 17:19:17 2013 From: 1184376 at bugs.launchpad.net (Barry Warsaw) Date: Tue, 28 May 2013 15:19:17 -0000 Subject: [Bug 1184376] Re: REST server crashes on "reopen" References: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Message-ID: <20130528151917.14537.49525.malone@soybean.canonical.com> To be honest, I don't remember why I added that. Note that the REST server is the only one that doesn't intercept signals. I tried commenting out that line (since the default is True) and cli testing seemed just fine. The test suite passes too. I wonder if it was due to a problem in Python 2.6 which perhaps is fixed now in 2.7? Try commenting out line 43 in rest.py and see if things work better for you. If so, then perhaps we can just remove this mis-feature. I sure wish I remembered why I added it though. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1184376 Title: REST server crashes on "reopen" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1184376/+subscriptions From aurelien at bompard.org Tue May 28 17:34:04 2013 From: aurelien at bompard.org (=?utf-8?q?Aur=C3=A9lien_Bompard?=) Date: Tue, 28 May 2013 15:34:04 -0000 Subject: [Bug 1184376] Re: REST server crashes on "reopen" References: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Message-ID: <20130528153405.7272.37372.malone@chaenomeles.canonical.com> I've been running without this line for a few days already, and it seems to work fine. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1184376 Title: REST server crashes on "reopen" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1184376/+subscriptions From mark at msapiro.net Thu May 30 19:43:50 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 30 May 2013 17:43:50 -0000 Subject: [Bug 886296] Re: Improve DSN handling for google 'inactive' accounts References: <20111104184444.5805.4293.malonedeb@gac.canonical.com> Message-ID: <20130530174351.6151.35621.launchpad@chaenomeles.canonical.com> ** Changed in: flufl.bounce Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/886296 Title: Improve DSN handling for google 'inactive' accounts To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/886296/+subscriptions From 1184376 at bugs.launchpad.net Thu May 30 23:47:35 2013 From: 1184376 at bugs.launchpad.net (Barry Warsaw) Date: Thu, 30 May 2013 21:47:35 -0000 Subject: [Bug 1184376] Re: REST server crashes on "reopen" References: <20130526163258.7720.51480.malonedeb@chaenomeles.canonical.com> Message-ID: <20130530214735.4299.48718.malone@soybean.canonical.com> Okay, I've commented out the line in RESTRunner, but not removed the basic functionality to override interception of signals. That way, if I remember why I added that in the first place, it will be easier to re- enable. OTOH, if nothing bad happens, then we should eventually remove the flag. ** Changed in: mailman Milestone: None => 3.0.0b4 ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Status: New => Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1184376 Title: REST server crashes on "reopen" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1184376/+subscriptions From mark at msapiro.net Fri May 31 00:16:07 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 30 May 2013 22:16:07 -0000 Subject: [Bug 1079254] Re: Doesn't handle sendmail bounces properly References: <20121115154529.17370.55566.malonedeb@wampee.canonical.com> Message-ID: <20130530221608.27234.55042.launchpad@gac.canonical.com> ** Changed in: flufl.bounce Importance: Undecided => Low ** Changed in: flufl.bounce Status: New => Fix Committed ** Changed in: flufl.bounce Milestone: None => 2.2 ** Changed in: flufl.bounce Assignee: (unassigned) => Mark Sapiro (msapiro) ** Also affects: mailman Importance: Undecided Status: New ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079254 Title: Doesn't handle sendmail bounces properly To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079254/+subscriptions From mark at msapiro.net Fri May 31 00:18:05 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 30 May 2013 22:18:05 -0000 Subject: [Bug 1079249] Re: mail.ru bounces support References: <20121115153334.5140.47622.malonedeb@soybean.canonical.com> Message-ID: <20130530221805.27632.91490.launchpad@gac.canonical.com> ** Changed in: flufl.bounce Importance: Undecided => Medium ** Changed in: flufl.bounce Status: New => Fix Committed ** Changed in: flufl.bounce Milestone: None => 2.2 ** Changed in: flufl.bounce Assignee: (unassigned) => Mark Sapiro (msapiro) ** Also affects: mailman Importance: Undecided Status: New ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079249 Title: mail.ru bounces support To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079249/+subscriptions From mark at msapiro.net Fri May 31 00:19:26 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 30 May 2013 22:19:26 -0000 Subject: [Bug 1074592] Re: Qmail detector fails on non-ASCII messages References: <20121103083426.19132.72322.malonedeb@soybean.canonical.com> Message-ID: <20130530221926.27733.94760.launchpad@gac.canonical.com> ** Also affects: mailman Importance: Undecided Status: New ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1074592 Title: Qmail detector fails on non-ASCII messages To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1074592/+subscriptions From 1181498 at bugs.launchpad.net Fri May 31 00:27:35 2013 From: 1181498 at bugs.launchpad.net (Barry Warsaw) Date: Thu, 30 May 2013 22:27:35 -0000 Subject: [Bug 1181498] Re: subject_prefix is not part of the IMailingList interface References: <20130518103509.15387.12066.malonedeb@chaenomeles.canonical.com> Message-ID: <20130530222735.10279.94016.malone@wampee.canonical.com> Note that what really happens is that the display name is taken as the default, initial value of the text to put inside the square brackets, when the default style is used. See src/mailman/styles/base.py for details. Thanks for noting this. I will add subject_prefix to the interface and update the display_name docstring. ** Changed in: mailman Milestone: None => 3.0.0b4 ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1181498 Title: subject_prefix is not part of the IMailingList interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1181498/+subscriptions From rkw at dataplex.net Fri May 31 04:31:28 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Fri, 31 May 2013 02:31:28 -0000 Subject: [Merge] lp:~wacky/postorius/GSoC2012 into lp:postorius Message-ID: <20130531023127.16308.6928.launchpad@ackee.canonical.com> Richard Wackerbarth has proposed merging lp:~wacky/postorius/GSoC2012 into lp:postorius. Requested reviews: Florian Fuchs (flo-fuchs) For more details, see: https://code.launchpad.net/~wacky/postorius/GSoC2012/+merge/166629 Changes from GSoc2012. Each commit is a separate patch. -- https://code.launchpad.net/~wacky/postorius/GSoC2012/+merge/166629 Your team Mailman Coders is subscribed to branch lp:postorius. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 18999 bytes Desc: not available URL: From 1079254 at bugs.launchpad.net Fri May 31 04:33:30 2013 From: 1079254 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 31 May 2013 02:33:30 -0000 Subject: [Bug 1079254] Re: Doesn't handle sendmail bounces properly References: <20121115154529.17370.55566.malonedeb@wampee.canonical.com> Message-ID: <20130531023333.10017.64749.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079254 Title: Doesn't handle sendmail bounces properly To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079254/+subscriptions From mark at msapiro.net Fri May 31 04:34:19 2013 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 31 May 2013 02:34:19 -0000 Subject: [Bug 1079254] Re: Doesn't handle sendmail bounces properly References: <20121115154529.17370.55566.malonedeb@wampee.canonical.com> Message-ID: <20130531023421.10241.5880.launchpad@wampee.canonical.com> ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.16 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079254 Title: Doesn't handle sendmail bounces properly To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079254/+subscriptions From 1079249 at bugs.launchpad.net Fri May 31 04:33:30 2013 From: 1079249 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 31 May 2013 02:33:30 -0000 Subject: [Bug 1079249] Re: mail.ru bounces support References: <20121115153334.5140.47622.malonedeb@soybean.canonical.com> Message-ID: <20130531023332.10017.85135.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079249 Title: mail.ru bounces support To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079249/+subscriptions From 1074592 at bugs.launchpad.net Fri May 31 04:33:30 2013 From: 1074592 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 31 May 2013 02:33:30 -0000 Subject: [Bug 1074592] Re: Qmail detector fails on non-ASCII messages References: <20121103083426.19132.72322.malonedeb@soybean.canonical.com> Message-ID: <20130531023332.10017.12204.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1074592 Title: Qmail detector fails on non-ASCII messages To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1074592/+subscriptions From mark at msapiro.net Fri May 31 04:36:16 2013 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 31 May 2013 02:36:16 -0000 Subject: [Bug 1079249] Re: mail.ru bounces support References: <20121115153334.5140.47622.malonedeb@soybean.canonical.com> Message-ID: <20130531023616.4335.37771.malone@soybean.canonical.com> Thanks for the patch including the test case. ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.16 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1079249 Title: mail.ru bounces support To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1079249/+subscriptions From mark at msapiro.net Fri May 31 04:44:37 2013 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 31 May 2013 02:44:37 -0000 Subject: [Bug 1074592] Re: Qmail detector fails on non-ASCII messages References: <20121103083426.19132.72322.malonedeb@soybean.canonical.com> Message-ID: <20130531024438.10368.49733.malone@wampee.canonical.com> The Qmail detector didn't fail in MM 2.1, but I included the test case from flufl.bounce rev 36. ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.16 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1074592 Title: Qmail detector fails on non-ASCII messages To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1074592/+subscriptions