Bugs item #663675, was opened at 2003-01-07 08:02
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=663675&group_i…
Category: Web/CGI
Group: 2.1 (stable)
>Status: Closed
>Resolution: Works For Me
Priority: 7
Submitted By: Fabricio Chalub (chalub)
Assigned to: Nobody/Anonymous (nobody)
Summary: Administrative interface vs. non-standard HTTP ports
Initial Comment:
I still find that mailman's administrative interface
behaves incorrectly on HTTPDs running on non-standard
ports. It simply discards the port information out of
the URL, despite DEFAULT_URL* settings.
On some pages, the URL to the FORM ACTION is relative
(eg, the "General Options" form) while others, it is
absolute (eg, the "Membership list").
Looking around the source, I've found lines like this
(on Mailman/Cgi/admin.py)
adminurl = mlist.GetScriptURL('admin', absolute=1)
Changing the value of ABSOLUTE to 0 solved the problem,
and I've found it pretty harmless. Any specific reason
for the ABSOLUTE=1 setting?
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 18:55
Message:
Logged In: YES
user_id=12800
We had lots of problems when non-absolute urls where used,
although I don't remember the exact details of the problems.
Eventually we'll probably make all urls absolute and get
rid of this argument to GetScriptURL().
BTW, this works for me, so I'm closing the bug report. Note
that changing the DEFAULT_URL_* variables does not change
settings for existing lists. For those you must use
bin/withlist to change the web_page_url variable manually.
If there are specific links that are broken, then please
follow up with those links and I'll look into them.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=663675&group_i…
Bugs item #611185, was opened at 2002-09-18 13:23
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=611185&group_i…
Category: command line scripts
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Linda Julien (leira)
Assigned to: Nobody/Anonymous (nobody)
Summary: rmlist doesn't delete lock files
Initial Comment:
I'm using 2.0.13.
The rmlist script doesn't delete lock files associated
with the list (if any exist).
Removing a list and creating a new one with the same
name can have unexpected results.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-15 12:02
Message:
Logged In: YES
user_id=12800
Promoting this to a 2.1 (stable) bug, since I doubt the
code's changed much here. Need to double check.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=611185&group_i…
Bugs item #665791, was opened at 2003-01-10 10:12
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=665791&group_i…
Category: Pipermail
Group: 2.1 (stable)
>Status: Closed
>Resolution: Out of Date
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hiding e-mail addresses breaks mbox archives
Initial Comment:
(Noticed in the archives for the pycon-organizers list)
The archiver will generate mbox separator lines
that look like this:
>From sholden at holdenweb.com Fri Jan 3 03:53:20 2003
This breaks at least mutt's mbox parsing. The line should use
unaltered e-mail address.
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 18:19
Message:
Logged In: YES
user_id=12800
I believe this was fixed in Mailman 2.1.1 (or at least it's
now fixed in cvs for 2.1.2).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=665791&group_i…
Bugs item #667167, was opened at 2003-01-13 09:11
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=667167&group_i…
Category: Web/CGI
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: John Swartzentruber (jswartzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-digest options configuration help
Initial Comment:
It would be helpful if the personalized footer fields (eg
user_address or user_name) were also listed in
the "Details for msg_footer". Or at least a mention that
they are listed in the "Details for personalize".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=667167&group_i…
Bugs item #667232, was opened at 2003-01-13 11:20
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=667232&group_i…
Category: mail delivery
Group: 2.1 (stable)
>Status: Closed
>Resolution: Out of Date
Priority: 7
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Collapse CC: header
Initial Comment:
Some email tools adhere strictly to RFC 2822, which
mandates exactly one CC header. Other tools are more
lenient and allow multiple CC headers. To interoperate
better with more strict tools, Mailman should accept
multiple CC headers (it already does) and it should
collapse them to a single CC header even if not doing
header munging.
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 17:27
Message:
Logged In: YES
user_id=12800
We do this when we do reply-to munging, which ought to be
good enough. Mailman shouldn't compensate for overly strict
tools if the original message's CC headers aren't fully
compliant.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=667232&group_i…
Bugs item #662472, was opened at 2003-01-04 23:38
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=662472&group_i…
Category: None
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jorge Becerra (jlbpcuba)
Assigned to: Nobody/Anonymous (nobody)
Summary: scrubber arbitrary extension change for attachments
Initial Comment:
the archiver scrubber seems to honor the mimetypes, but not the
file extensions.
He change the extension other , even when
use some that have the same mimetypes and donŽt keep the
same, he changes to the first with the same mimetypes taked from
mimetypes.py or some other order.
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 17:25
Message:
Logged In: YES
user_id=12800
I believe this has been fixed for Mailman 2.1.2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=662472&group_i…
Bugs item #662490, was opened at 2003-01-05 01:44
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=662490&group_i…
Category: Web/CGI
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jorge Becerra (jlbpcuba)
Assigned to: Nobody/Anonymous (nobody)
Summary: not mimetype return
Initial Comment:
Attachments acces using the Mailman cgi-wrapper (private) donŽt
get the proper mimetype
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=662490&group_i…
Bugs item #659011, was opened at 2002-12-27 09:10
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=659011&group_i…
Category: command line scripts
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jost Krieger (jkrieger)
Assigned to: Nobody/Anonymous (nobody)
Summary: add_members -c publishes member list
Initial Comment:
add_members -c uses Message.UserNotification
for the "Big changes" message. This puts all
recipients into the "To:" field, which has already lead
to a privacy complaint at our site.
Of course it's also a Really Bad Idea with large lists.
Jost
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 17:20
Message:
Logged In: YES
user_id=12800
I've decided instead to remove -c / --changes-msg.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=659011&group_i…
Bugs item #670535, was opened at 2003-01-18 22:04
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_i…
Category: mail delivery
Group: 2.1 (stable)
>Status: Pending
Resolution: None
Priority: 8
Submitted By: David Gibbs (midrangeman)
Assigned to: Nobody/Anonymous (nobody)
Summary: qrunner stops for no apparent reason
Initial Comment:
About once every day or so, qrunner will stop for no
apparent reason.
The qrunner log file has the following ...
Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner
exiting.
Jan 18 14:29:09 2003 (3441) BounceRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3441) BounceRunner qrunner
exiting.
Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner
exiting.
Jan 18 14:29:09 2003 (3442) CommandRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3442) CommandRunner qrunner
exiting.
Jan 18 14:29:09 2003 (3446) VirginRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3446) VirginRunner qrunner
exiting.
Jan 18 14:29:09 2003 (3440) ArchRunner qrunner caught
SIGTERM. Stopping.
Jan 18 14:29:09 2003 (3440) ArchRunner qrunner exiting.
Jan 18 14:29:10 2003 (3444) NewsRunner qrunner
caught SIGTERM. Stopping.
Jan 18 14:29:12 2003 (3444) NewsRunner qrunner
exiting.
No other log has any indication of what might be
happening.
Is there a way to increase the logging somewhere so the
cause can be identified?
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 16:51
Message:
Logged In: YES
user_id=12800
David, have you been able to dig up more information about
this problem?
I'm moving this to Pending as we have no clue why it's
happening for you and cannot reproduce it on any systems we
have available to us.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2003-03-21 19:54
Message:
Logged In: YES
user_id=34209
No, having multiple versions of Python should not be causing
this. Nor should the SIGALRM handler being triggered cause
it, unless something is seriously broken in your setup --
but we've already been there.
The only way to see if a SIGTERM is actually being delivered
is running the processes under strace or gdb, but this
seriously disrupts regular operation. There is no way that i
know of to find out where a signal is coming from, once you
find out that it really is a signal. If it *isn't* a real
signal, I would start looking at libc bugs and other
platform bugs. You can try upgrading Python to 2.2.2 (the
latest bugfix release) but I would be very suprised if it
fixed your problem. RedHat does not have a great reputation
for stability, so be sure to check for any RedHat updates.
----------------------------------------------------------------------
Comment By: David Gibbs (midrangeman)
Date: 2003-03-17 12:44
Message:
Logged In: YES
user_id=86339
Additional environment details:
Redhat Linux 8.0, uname = "Linux xxx.midrange.com 2.4.18-
26.8.0 #1 Mon Feb 24 10:21:42 EST 2003 i686 i686 i386
GNU/Linux"
Python: 2.2.1
CPU: P4 2.4ghz, 512mb RAM
Dunno if this makes a difference, but I have the following
directories ...
/usr/lib/python1.5
/usr/lib/python2.1
/usr/lib/python2.2
Any chance there is a conflict?
----------------------------------------------------------------------
Comment By: David Gibbs (midrangeman)
Date: 2003-01-24 13:31
Message:
Logged In: YES
user_id=86339
I added some debug code to mailmanctl and found out that the
sigalarm handler is firing just before the qrunners are terminating.
----------------------------------------------------------------------
Comment By: David Gibbs (midrangeman)
Date: 2003-01-22 16:31
Message:
Logged In: YES
user_id=86339
After some further research, QRUNNER seems to stop after
exactly 24 hours of operation. That is, 24 hours after qrunner
starts, it ends as if someone killed it with SIGTERM. I know
for a fact that nobody is actually doing this ... and no process
on my system should be aware of the fact that qrunner is
actually running.
I will not discount the possiblity that this is an environmental
factor, but it seems to me that a daemon process should not
be affected by environmental factors.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-19 17:46
Message:
Logged In: YES
user_id=12800
I'm not sure what kind of logging would help. Some process
somewhere is SIGTERMing the mailmanctl controller process.
There's no way to know where a signal is coming from, so I'm
not sure what more you could do in mailmanctl.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_i…
Bugs item #716702, was opened at 2003-04-07 08:21
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=716702&group_i…
Category: command line scripts
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bartosz Sawicki (sawickib)
Assigned to: Nobody/Anonymous (nobody)
Summary: checkdbs i18n
Initial Comment:
I've found phrase that could not be translated:
Action: dailly checkdbs run
Message: reason for pending posts eg.
"Post by non-member to a members-only list"
In code: bin/checkdbs, line 114, there is:
when, sender, subject, reason, text, msgdata =
mlist.GetRecord(id)
date = time.ctime(when)
pending.append(_("""\
From: %(sender)s on %(date)s
Subject: %(subject)s
Cause: %(reason)s"""))
As you see none of "when, sender, subject, reason,
text, msgdata" are beeing translated. I agree, that
translation of sender or subject is unwated, but
variables 'date' and 'reason' should be translated.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=716702&group_i…