Public bug reported:
The usage function defined in cron/gate_news defines its first argument
as 'status' but then refers to it as 'code'.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: 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/721015
Title:
Typo in cron/gate_news usage() definition.
Public bug reported:
The listname in @listname entries in *_these_nonmembers should be lower-
cased before attempting to instantiate the list.
** Affects: mailman
Importance: Low
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/705715
Title:
@listname entries in *_these_nonmembers are case sensitive.
Public bug reported:
bin/rmlist LISTNAME should remove any data/heldmsg-LISTNAME-* files.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: Triaged
** Changed in: mailman
Importance: Undecided => Low
** Changed in: mailman
Status: New => Triaged
** Changed in: mailman
Milestone: None => 2.1.15
** 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/700528
Title:
bin/rmlist does not remove the heldmsg-LISTNAME-* files for the list.
Public bug reported:
We're running Mailman 2.1.14 and have recently begun using mm-
handler-2.1.10 from the contrib directory as MTA for sendmail.
Everything appeared to work fine, but after a few months we were alerted
by one of our users that no mail was delivered anymore to one of his
lists. The list's name is mathematica-admin. It turns out that mm-
handler strips the -admin part and tries to deliver the mail to a list
named mathematica, which does not exist. We had a small number of other
lists with the same problem. I've created a patch that fixes it and
another small issue (a variable is passed to a subroutine, but a global
variable is actually used there).
** 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/697161
Title:
Bug in mm-handler-2.1.10 regarding lists named xxx-admin
Public bug reported:
Steps to reproduce:
Create two mail lists ml01 (hosted on domain dom.1) and ml02 (hosted on
domain dom.2)
Add user to ml01
$ add_members -a y -r - ml01
lkjhlkhlkh(a)wefqwefqwef.com
Subscribed: lkjhlkhlkh(a)wefqwefqwef.com
Notification email to the admin of ml01 will look as following:
Subject: Ml01 subscription notification
From: mailman(a)dom.2
To: mladmin00(a)dom.1
Message-ID: <mailman.1.1287993063.7501.ml01(a)dom.1>
Date: Mon, 25 Oct 2010 14:51:03 +0700
Subscribed: lkjhlkhlkh(a)wefqwefqwef.com
Apparently, host name of the mail list is not considered when composing the notification message.
I've checked 2.1.9 and 2.1.14 - both have the same bug
** Affects: mailman
Importance: Undecided
Status: New
--
wrong From field in subscription notification to admin
https://bugs.launchpad.net/bugs/666181
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
If OutgoingRunner's attempt to connect to the outgoing SMTP server
results in socket.error, OutgoingRunner requeues the message and
continues processing without delay resulting in continuously looping
over the queue until the socket.error is somehow resolved.
** 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/966531
Title:
OutgoingRunner consumes 100% cpu
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/966531/+subscriptions
Public bug reported:
The fix for bug #629738 decodes base64 and quoted-printable message
bodies for display in the admindb held message display. If the decoded
message body contains characters not representable in the character set
of the list's preferred language, an uncaught UnicodeDecodeError can
result when formatting the message for web display.
** 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/910440
Title:
Admindb interface can crash with a UnicodeDecodeError when displaying
held message contents.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/910440/+subscriptions
Public bug reported:
Hi
I use mailman-2.1.14-6 on fedora 15
When I use english regex topics, all works good.
If I use russian regex, subscribers-members of a topic don't receive
e-mails. Bacause subject doesn't match with regex.
In source code(/usr/lib/mailman/Mailman/Handlers/Tagger.py) I found that
subject doesn't modified from MIME format.
If it english all seem good, but in my case I saw:
pattern is "<C8><D5><CA>"
line is "=?KOI8-R?Q?=C8=D5=CA?="
I create simple patch that use decode_header function from email module
** Affects: mailman
Importance: Undecided
Status: New
** Tags: charset header mailman topics
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/891676
Title:
topics don't work with national(russian) languages
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/891676/+subscriptions
Public bug reported:
(From a recent post to mailman-users(a)python.org)
I usually use the web interface for approving messages. But I
occasionally do it via Email. When I do, I get a response back that looks
like this:
The results of your email command are provided below. Attached is your
original message.
- Results:
Confirmation succeeded
- Unprocessed:
Approved: <admin password>
- Done.
---- CUT HERE -----------------------
To me at least, this suggests that the message has been rejected, not
approved, as the text says that the approval command was not processed.
I know this isn't the case because I see the message posted to the list,
but when I initially saw it, I had a panic as I thought I'd lost a message
for the list.
Is it possible to fix this so that the message is more clear about what
has happened? The "Confirmation succeeded" message is not very
explanatory, and seen in isolation doesn't really tell you anythying about
whether the message was approved or rejected.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: 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/889968
Title:
Response to email approval of held message is misleading
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/889968/+subscriptions
Public bug reported:
The code in Mailman/Gui/General.py for setting new_member_options
doesn't take into account the fact that there might be option bits other
than 'hide', 'ack', 'notmetoo' and 'nodupes' that are set, and it resets
them even if the four displayed options are unchanged. This also affects
bin/config_list which cannot set bits other than those 4 unless set via
mlist.new_member_options =.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: 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/865825
Title:
Undisplayed new_member_options bits are reset whenever the General
Options page is submitted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/865825/+subscriptions