Mailman 3 June 2014 - Mailman-coders

[Bug 1091586] [NEW] Frequent OperationalError: database is locked with sqlite
by Aurélien Bompard Nov. 26, 2014

Nov. 26, 2014

Public bug reported: I'm seeing frequent locking errors with SQLite on the current version of mailman3 from bzr. Here's an example traceback : Traceback (most recent call last): File "/srv/dev/mailman/bin/runner", line 9, in <module> load_entry_point('mailman==3.0.0b2-', 'console_scripts', 'runner')() File "/srv/dev/mailman/mailman3/mailman/src/mailman/bin/runner.py", line 253, in main runner.run() File "/srv/dev/mailman/mailman3/mailman/src/mailman/core/runner.py", line 96, in run filecnt = self._one_iteration() File "/srv/dev/mailman/mailman3/mailman/src/mailman/core/runner.py", line 173, in _one_iteration config.db.commit() File "/srv/dev/mailman/mailman3/mailman/src/mailman/database/base.py", line 77, in commit self.store.commit() File "/srv/dev/mailman/lib/python2.6/site-packages/storm-0.19-py2.6-linux-x86_64.egg/storm/store.py", line 122, in commit self._connection.commit() File "/srv/dev/mailman/lib/python2.6/site-packages/storm-0.19-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 126, in commit self.raw_execute("COMMIT", _end=True) File "/srv/dev/mailman/lib/python2.6/site-packages/storm-0.19-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 154, in raw_execute return Connection.raw_execute(self, statement, params) File "/srv/dev/mailman/lib/python2.6/site-packages/storm-0.19-py2.6-linux-x86_64.egg/storm/database.py", line 322, in raw_execute self._check_disconnect(raw_cursor.execute, *args) File "/srv/dev/mailman/lib/python2.6/site-packages/storm-0.19-py2.6-linux-x86_64.egg/storm/database.py", line 371, in _check_disconnect return function(*args, **kwargs) sqlite3.OperationalError: database is locked It happens during the normal processing of Mailman, not while using the API (to my knowledge), so it seems different from bug #856004. I can reproduce this easily by letting Mailman work for some time. After the locking error, new messages are stuck in var/queue/pipeline: $ ls var/queue/* var/queue/archive: var/queue/bad: var/queue/bounces: var/queue/command: var/queue/digest: var/queue/in: var/queue/lmtp: var/queue/nntp: var/queue/out: var/queue/pipeline: 1355781960.9870529+18f0acdf07aab616f793ecf76acfa1994e62b3a9.pck 1355799347.787621+213f3a6a971717ad1ba27f3d56b65767747a45da.pck 1355814973.8623891+4e66eeadef9b8c9ae99e4ed022c6c93f5af75c05.pck 1355782349.546113+ee14cb323574b647d9014f742e3f505e388d553e.pck 1355800543.460628+c455625c1ad86a5a77c9c515fcb6d555ba439b19.pck 1355815808.8860879+ca3fb5f45999e47c92756489daa951672ba4304d.pck 1355792739.8787439+19973fbcf763f036655aa0a7d477231246afdfbd.pck 1355802301.7830889+7989a3199c7eb491b65176937c0c1658cca9d46d.pck 1355820018.1813829+5005ded04da3574a7f3cd7472c9d635c577b6c32.pck 1355794764.597765+6cf379ad16c948117bb65f0aed0b3c230268ffd2.pck 1355803681.7455051+52d185cdcaecaf883bd43f375f5253567f5cd568.pck 1355822188.0491021+6a3cab9831d03b4f94475f745fa508c5126116b4.pck 1355794889.8323901+e14e25e342ec59709266040d830d7e12be2a1261.pck 1355805362.052228+422e573a6117edb7aae1acf9150ac58c210cedba.pck 1355822293.2363911+627f13dd2121bcb0f1916bc0448cc3b8adc9ad1f.pck 1355795937.2442579+62193d05ee80c6a22213cf2ff211c135fb7d38d9.pck 1355807374.9844501+8de57ab53819fac59d64705bcc56f86899d22634.pck 1355798662.8335559+554da4e7690e116e6fabee5764ac69829dc25685.pck 1355808273.143533+ed1acbf580c596ed921e062ece575877f0c9304b.pck var/queue/rest: var/queue/retry: var/queue/shunt: 1355776302.1302171+c657867b33bf6e37554ff83ee26f4096a77c1114.pck var/queue/virgin: And I need to restart mailman to make it process them again. The locked caused the message to be shunted. I'll attach the mailman.log file, where you'll see many "database is locked" errors, happening on different requests. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1091586 Title: Frequent OperationalError: database is locked with sqlite To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1091586/+subscriptions

2 8

[Bug 1236297] [NEW] Unicode errors with PostgreSQL and RawStr fields
by Aurélien Bompard Nov. 26, 2014

Nov. 26, 2014

Public bug reported: When using PostgreSQL as a database, it's impossible to set the moderator_password field of a mailing list, which is of type RawStr. To be precise, it's possible to set it, but getting it back from the database after a commit will cause a TypeError with the message: "Expected str, found <type 'unicode'>" as if PostgreSQL always returned unicode on TEXT fields and Storm did not convert them to bytestrings. I get no errors on an SQLite database. I don't know if the problem comes from Mailman or Storm. I have written a python script to reproduce it, see the attached file. There are comments, it should be easily readable. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 ** Attachment added: "test-mm-storm-unicode.py" https://bugs.launchpad.net/bugs/1236297/+attachment/3864008/+files/test-mm-… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1236297 Title: Unicode errors with PostgreSQL and RawStr fields To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1236297/+subscriptions

2 5

[Bug 1230130] [NEW] The mailinglist interface specifies the "administrative" attribute instead of "administrivia"
by Aurélien Bompard Nov. 25, 2014

Nov. 25, 2014

Public bug reported: In the IMailingList interface, there is an "administrative" attribute which is said to control "administrivia" checks. But apparently, in the model and in the code, this attribute is called "administrivia", as in Mailman 2.1. Unless I'm missing something, the interface attribute should be renamed. ** Affects: mailman Importance: Undecided Status: New ** Tags: easy 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/1230130 Title: The mailinglist interface specifies the "administrative" attribute instead of "administrivia" To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1230130/+subscriptions

1 1

[Bug 1082746] [NEW] Automated processes can swamp a list with web subscription requests.
by Mark Sapiro Oct. 2, 2014

Oct. 2, 2014

Public bug reported: There are discussions of this in threads at <http://mail.python.org/pipermail/mailman- users/2012-October/074213.html>, <http://mail.python.org/pipermail /mailman-users/2012-October/074278.html> and <http://mail.python.org/pipermail/mailman- users/2012-November/074412.html>. The Mailman developers do not think there is any way to prevent this other that disabling web subscribe entirely, as by definition, subscription requests come from unauthenticated users. However, an attempt will be made to mitigate this by making a site option to include a dynamically generated hidden hash in the subscribe form which will at least require an automated process to first GET and parse the listinfo form immediately prior to POSTing it. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1082746 Title: Automated processes can swamp a list with web subscription requests. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1082746/+subscriptions

3 8

[Bug 1325568] [NEW] pseudo anonymous list feature
by Christian Burger Sept. 19, 2014

Sept. 19, 2014

Public bug reported: Hey there, I wanted to have a pseudo anonymous list. Meaning: The sender's e-mail address is rewritten to the list's address, but the name in "From:" is set to the member's name stored in the mailing list database. It's an extension to the "anonymous_list" feature. Let's say we have a list 'exlist' sending from "examplelist(a)example.com" with a member "John Doe" writing from "john(a)example.net". If his name is set in the mailing list configuration, and "anonymous_list" as well as the "pseudo_anonymous_list" feature is turned on, the original "From:" in John Doe's messages is rewritten to "John Doe <examplelist(a)example.com>". So his e-mail address stays private, but the message can be recognized easily as being from him. I don't know if that goes against any standards. Maybe it should be "John Doe via exlist <examplelist(a)example.com>" to emphasize the it is a list message. Just a thought. I didn't find a configuration providing that feature in mailman -- hope I did not overlook anything. I attached a small patch based upon http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1436 I could take a shot at integrating it into the latest revision of the 2.1 branch if there is any interest in that feature. If you want to try the patch, you have to execute 'bin/withlist -r add_pseudo_anonymous_list -a' for old lists to have the new configuration value. I did not test the feature thoroughly, but it seems to work on my server. Thanks and bye, Christian ** Affects: mailman Importance: Undecided Status: New ** Patch added: "patch based upon branch 2.1 (rev 1436)" https://bugs.launchpad.net/bugs/1325568/+attachment/4124119/+files/pseudo_a… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1325568 Title: pseudo anonymous list feature To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1325568/+subscriptions

2 6

[Bug 1263247] [NEW] Bounce warnings from kundenserver.de are not recognized
by Mark Sapiro Aug. 18, 2014

Aug. 18, 2014

Public bug reported: The warning message is not recognized as such causing a bounce to be recorded in a VERP environment for a message that's simply delayed. ** Affects: flufl.bounce Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress ** Changed in: mailman Milestone: None => 2.1.18 ** Also affects: flufl.bounce Importance: Undecided Status: New ** Changed in: flufl.bounce Importance: Undecided => Low ** Changed in: flufl.bounce Status: New => In Progress ** Changed in: flufl.bounce 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/1263247 Title: Bounce warnings from kundenserver.de are not recognized To manage notifications about this bug go to: https://bugs.launchpad.net/flufl.bounce/+bug/1263247/+subscriptions

3 6

[Bug 266391] Re: difficult to use radio and check boxes in admin interface
by Mark Sapiro June 9, 2014

June 9, 2014

Although this and two of the duplicates appear to address only the list admin UI, the third duplicate (LP: #558227) addresses the admindb UI. The committed fix addresses both except for the held message action radio buttons in the admindb UI. These weren't addressed in the submitted patch for LP: #558227 either, so I think it's fair to consider all four to be fixed. ** Changed in: mailman Importance: Medium => Low ** Changed in: mailman Status: Confirmed => Fix Committed ** Changed in: mailman Milestone: 2.1-stable => 2.1.19 ** 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/266391 Title: difficult to use radio and check boxes in admin interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266391/+subscriptions

1 0

[Bug 266391] Re: difficult to use radio and check boxes in admin interface
by Launchpad Bug Tracker June 9, 2014

June 9, 2014

** 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/266391 Title: difficult to use radio and check boxes in admin interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266391/+subscriptions

1 0

[Bug 1328255] [NEW] From: munging is ugly if there is no realname
by Joe Pfeiffer June 9, 2014

June 9, 2014

Public bug reported: A user on a list I administer posted a message with only an email address, and no real name, in his From: line. Like this: From: user(a)example.com With From: munging enabled, this resulted in a From: line of From: via list <list(a)example.com> The attached patch forges a realname based on the user's email address in this circumstance, giving a From: line like From: user AT example DOT com via list <list(a)example.com> ** Affects: mailman Importance: Undecided Status: New ** Patch added: "patch to forge realnames" https://bugs.launchpad.net/bugs/1328255/+attachment/4128427/+files/mailman.… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1328255 Title: From: munging is ugly if there is no realname To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1328255/+subscriptions

2 1

[Bug 266391] Re: difficult to use radio and check boxes in admin interface
by Pasi Lallinaho June 9, 2014

June 9, 2014

There is a one-line patch for this issue against an older Mailman version in the duplicate bug #558028. ** Changed in: mailman Status: New => Confirmed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266391 Title: difficult to use radio and check boxes in admin interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266391/+subscriptions

1 0