Public bug reported:
During testing I encountered, that bin/mailman is not working correctly
if you supply a relative path as -C argument. For the main process the
path is converted into a absolute path during startup but the bin/master
process is getting the relative filename but maybe a different working
directory.
The attached patch fixes that behavior by supplying the generated
absolute pathname to the new process.
** 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/1023681
Title:
bin/mailman -C config start does not work with a relativ config path
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1023681/+subscriptions
Public bug reported:
When admin_immed_notify is Yes and subscribe_policy is approve, the
Subject: of the notice to the admin is in the user's preferred language
rather than the list's preferred language and it may not be properly RFC
2047 encoded.
** Affects: mailman
Importance: Undecided
Status: New
** Affects: mailman/2.1
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** Affects: mailman/3.0
Importance: Undecided
Status: New
** Tags: mailman3
** Also affects: mailman/2.1
Importance: Undecided
Status: New
** Also affects: mailman/3.0
Importance: Undecided
Status: New
** Tags added: mailman3
** Changed in: mailman/2.1
Importance: Undecided => Medium
** Changed in: mailman/2.1
Status: New => In Progress
** Changed in: mailman/2.1
Milestone: None => 2.1.15
** Changed in: mailman/2.1
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/998949
Title:
Admin notice of held subscription is not fully in list's preferred
language.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/998949/+subscriptions
Public bug reported:
The draft for archival hashes for mailman specifies 32 character, base
32 encoding. We can get away with 13 characters which expects the first
collision at around 50 billion messages. The the wikipedia charts in
their "birthday attack" article. It's not like an occasional collision
is a big deal and this is not a security issue.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
** Tags added: 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/987031
Title:
archival hashes can be shortened
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/987031/+subscriptions
Public bug reported:
I've seen this error twice while running integration tests (of our own
application) that access Mailman 3 using the API. The load on Mailman is
very light, as all requests made to the API are serial, never in
parallel. Of course the various processing queues in MM3 are separate
processes and could be doing work concurrently.
The platform is Centos 6.
Traceback (most recent call last):
File "/usr/lib64/python2.6/wsgiref/handlers.py", line 93, in run
self.result = application(self.environ, self.start_response)
File "/home/sgoss/mailman_clone/src/mailman/rest/wsgiapp.py", line 63, in __call__
config.db.commit()
File "/home/sgoss/mailman_clone/src/mailman/database/stock.py", line 70, in commit
self.store.commit()
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/store.py", line 122, in commit
self._connection.commit()
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 126, in commit
self.raw_execute("COMMIT", _end=True)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 154, in raw_execute
return Connection.raw_execute(self, statement, params)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 321, in raw_execute
self._check_disconnect(raw_cursor.execute, *args)
File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 366, in _check_disconnect
return function(*args, **kwargs)
OperationalError: database is locked
The backend here is SQLite, which falls over very quickly under
concurrent load. If the goal here is to create a stable mailing list
server, maybe SQLite is a poor default.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 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/856004
Title:
"OperationalError: database is locked" encountered under very light
load while using REST API
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions
Public bug reported:
Not sure what caused this error that showed up in mailman.log:
Aug 16 10:54:50 2011 (31400) Uncaught runner exception: u'foo.example.com'
Aug 16 10:54:50 2011 (31400) Traceback (most recent call last):
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration
self._process_one_file(msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/runners/virgin.py", line 37, in _dispose
process(mlist, msg, msgdata, 'virgin')
File "/home/sgoss/mailman_clone/src/mailman/core/pipelines.py", line 50, in process
handler.process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 360, in process
process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 202, in process
listinfo = mlist.script_url('listinfo')
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 243, in script_url
return urljoin(self.domain.base_url, target + '/' + self.fqdn_listname)
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 227, in domain
return getUtility(IDomainManager)[self.mail_host]
File "/home/sgoss/mailman_clone/src/mailman/model/domain.py", line 142, in __getitem__
raise KeyError(email_host)
KeyError: u'foo.example.com'
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 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/827547
Title:
KeyError in "virgin" runner.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/827547/+subscriptions
Public bug reported:
Many large mailing lists use bracketed prefixes in subjects as a way to
filter messages into smaller buckets, allowing some subscribers to read
all mail sent to the list while allowing others to filter messages (in
their mail client) to read only the messages they are interested in.
For example, the W3C's www-style mailing list uses these tags to filter
messages based on which CSS spec they refer to. Thus, a subject line
that begins "[css3-fonts]" will be assumed to be about only the
css3-fonts spec, with a target audience of only those interested in that
particular spec and not, say, the css3-flexbox spec (whose subject lines
would be prefixed with "[css3-flexbox]").
To handle this, the Mailman archive interface would provide an option to
filter only on particular prefixes (as well as messages that don't have
any prefixes), allowing a user of the archive to use it as they
otherwise would, but filtering the output such that they only see the
messages they want to see, instead of the whole archive.
In addition, it would be helpful to allow mailing lists to automatically
prefix subject lines when the message is sent to an e-mail address using
a plus alias.
For example, sending mail to www-style+css3-fonts(a)w3.org would prefix
the subject line of the message with "[css3-fonts]" in the message sent
to subscribers and in the archive, whereas sending mail to www-
style+css3-flexbox(a)w3.org would prefix the message with
"[css3-flexbox]".
It should also be allowed to have multiple prefixes on a message, and
having such messages be treated as if they had any prefix individually.
In terms of plus aliasing, there are two ways to handle it: (1) allow
aliases to specify multiple prefixes in a plus alias using some
separator (e.g. a comma: www-style+css3-fonts,css3-flexbox(a)w3.org); or
(2) detecting and intercepting when a single message was sent to
multiple e-mail addresses with different plus aliases for a single
mailing list (e.g. sending the same e-mail to both www-
style+css3-fonts(a)w3.org and www-style+css3-flexbox(a)w3.org), treating it
as a single message with multiple subject prefixes when sent to
subscribers or stored in the archive.
Now, I understand that this is likely a huge undertaking, but I think it
would go a long way to helping users with large and diverse mailing
lists.
** 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/1082495
Title:
Support bracketed prefixes in subject as filters
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1082495/+subscriptions
Public bug reported:
It would be kind of nice for MM3 to implement a 'policy' command. If
you issue this email command, you would receive a response containing an
admin supplied policy text. This response should adhere to the general
grace period timeouts, and the text should be retrieved via the
generalized url retrieval and caching machinery. This way, the same
policy text could be retrievable via email command or web ui.
There should be a way to request policy documents in multiple languages.
** Affects: mailman
Importance: Wishlist
Status: New
** Tags: mailman3
** Changed in: mailman
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1070064
Title:
Add a 'policy' command
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1070064/+subscriptions
Public bug reported:
This is not a real bug, I would just like to start a discussion about
what can be done to set up a continuos integration system.
Is there any Jenkins server which can be used?
Another thing which I was thinking is if we have some real tests on
real systems with various MTA such as Postfix/Exim.
I haven't tried it yet but it seems that http://vagrantup.com/ and
puppet could really be very nice tools for the job.
And we could then
1. fire up a VM
2. install the different MTAs
3. create some complicated mailing lists and check that everything works correctly
Other ideas?
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 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/956384
Title:
Continuous integration and real-world testing
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/956384/+subscriptions
Public bug reported:
http://www.rfc-editor.org/rfc/rfc6783.txt
Mailing Lists and Non-ASCII Addresses
This needs to be reviewed for relevance to Mailman 3, likely with
separate bugs for any needed changes.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: 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/1076152
Title:
Review RFC 6783 for any needed changes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1076152/+subscriptions
Public bug reported:
Like this:
steve@turnbull:~/src/Mailman3/mailman-trunk$ python setup.py build_sphinx
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: invalid command 'build_sphinx'
For more information (version, configuration, and build log), see Bug
#1035057.
** 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/1035061
Title:
setup.py build_sphinx is broken
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1035061/+subscriptions