Patches item #657951, was opened at 2002-12-23 14:17
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…
Category: Pipermail
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generate RSS summary in archives
Initial Comment:
Here's a first-draft patch. Things that need fixing:
* The generated RSS feed needs to be validated. (It passed the
W3C's RDF validator, but RSS validators still need to be checked.)
* The date should be given in YYYY-MM-DD format, which requires
parsing the .fromdate attribute.
* How do I get the URL for an archived message? The generated RSS
currently just uses the filename, which is wrong. How do I get
at the PUBLIC_ARCHIVE_URL setting?
* Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them.
We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...)
* The list index page should have a LINK element pointing to
the RSS file.
Please make any comments you have, and I'll rework the patch accordingly.
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-18 18:43
Message:
Logged In: YES
user_id=12800
Andrew, to get the url for the archived message use
mlist.GetBaseArchiveURL(), which knows about private vs.
public archives, the host name and the list name. From
there you should be able to tack on just the part of the
path under "archives/private/listname". See
Mailman/Handlers/Scrubber.py for an example.
Only other minor comment: NUM_ARTICLES can probably go in
Defaults.py.in
----------------------------------------------------------------------
Comment By: Justin Mason (jmason)
Date: 2003-03-26 16:49
Message:
Logged In: YES
user_id=935
big thumbs up from me too. Much better solution than
http://taint.org/mmrss/ ;)
----------------------------------------------------------------------
Comment By: Uche Ogbuji (uche)
Date: 2003-03-17 20:09
Message:
Logged In: YES
user_id=38966
I'd like to add my vote to this item. This is a fantastic
idea, Andrew. Thanks.
--Uche
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-12-23 15:42
Message:
Logged In: YES
user_id=11375
Updated patch:
* Dates are now rendered as ISO-8601 (date only, not the time of the message)
* By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator.
----------------------------------------------------------------------
Comment By: captain larry (captainlarry)
Date: 2002-12-23 14:36
Message:
Logged In: YES
user_id=147905
Just voting for support here. This is *great* thanks for
the patch and I hope the maintainers include it as soon as
it's appropriate :)
Adam.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-12-23 14:27
Message:
Logged In: YES
user_id=12800
Deferring until post-2.1
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-12-23 14:21
Message:
Logged In: YES
user_id=11375
Argh; SF choked on the file upload. Attaching the patch again...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…
Bugs item #949117, was opened at 2004-05-06 08:16
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=949117&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configuring/installing
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brion Vibber (vibber)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1.5rc2 upgrade dies on corrupt qfiles
Initial Comment:
Upgrading from 2.1.2 to 2.1.5rc2; a couple of the .pck files in
qfiles/shunt were zero-length for reasons unknown.
This caused the upgrade (make install) to fail with this message:
updating old qfiles
Traceback (most recent call last):
File "bin/update", line 780, in ?
errors = main()
File "bin/update", line 709, in main
update_qfiles()
File "bin/update", line 441, in update_qfiles
msg, data = dequeue(filebase)
File "bin/update", line 497, in dequeue
msg = cPickle.load(msgfp)
EOFError
make: *** [update] Error 1
Removing the zero-length files cleared that up.
I did have one other problem; while investigating the first bit I
dumped some info to a text file in qfiles, and the next make install
failed with this error:
updating old qfiles
Traceback (most recent call last):
File "bin/update", line 780, in ?
errors = main()
File "bin/update", line 709, in main
update_qfiles()
File "bin/update", line 434, in update_qfiles
for filename in os.listdir(dirpath):
OSError: [Errno 20] Not a directory: '/home/mailman/qfiles/blork'
make: *** [update] Error 1
At least that had the filename in it. ;) Removed the file, and it
installed/upgraded cleanly. So far so good...
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-05-31 18:34
Message:
Logged In: YES
user_id=12800
Fixed for MM2.1.7
----------------------------------------------------------------------
Comment By: John Mora (jmoraragweed)
Date: 2004-05-25 10:34
Message:
Logged In: YES
user_id=605434
I have the same problem when trying to update to 2.1.5
release from Mailman version 2.1.4.
I have no zero-length files in qfiles/shunt.
My error is similar, but I'm not certain the two are
related. I'm posting it for lack of knowing better:
Updating Usenet watermarks
- nothing to update here
Nothing to do.
updating old qfiles
Traceback (most recent call last):
File "bin/update", line 780, in ?
errors = main()
File "bin/update", line 709, in main
update_qfiles()
File "bin/update", line 441, in update_qfiles
msg, data = dequeue(filebase)
File "bin/update", line 497, in dequeue
msg = cPickle.load(msgfp)
EOFError
make: *** [update] Error 1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=949117&group_i…
Bugs item #907272, was opened at 2004-02-29 23:10
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=907272&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: Out of Date
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nathan Stratton Treadway (nathanst)
Assigned to: Nobody/Anonymous (nobody)
Summary: URL given in UPGRADING no longer valid
Initial Comment:
I was just looking at the INSTALL document out of the
CSV (both the HEAD version and v2.11.2.1 that was
included in Mailman 2.1.4).
This document mentions the URL
http://mail.python.org/pipermail/mailman-users/2000-September/006826.html
which is supposed to be a message about upgrading the
list template files -- but the proper message is no
longer found at that URL.
I believe the intended message is now found at
http://mail.python.org/pipermail/mailman-users/2000-September/006822.html
If that's the right message, it problably makes sense
to give a little info to help people find the correct
message if it moves again (i.e. message dated Thu Sep
21 21:59:16 EDT 2000 and having a subject line of
"quick note for those ugrading mailman".
(Or, just quote the message directly in the INSTALL
document; it's not too long...)
Thanks.
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-05-31 18:15
Message:
Logged In: YES
user_id=12800
The INSTALL file was substantially rewritten for Mailman 2.1.6.
----------------------------------------------------------------------
Comment By: Nathan Stratton Treadway (nathanst)
Date: 2004-02-29 23:47
Message:
Logged In: YES
user_id=987478
Sorry, the file I was looking at was "UPGRADING", not "INSTALL".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=907272&group_i…
Patches item #839386, was opened at 2003-11-10 18:04
Message generated for change (Comment added) made by kyrian
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configure/install
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Kev Green (kyrian)
Assigned to: Nobody/Anonymous (nobody)
Summary: MySQL MemberAdaptor for Mailman 2.1
Initial Comment:
A MemberAdaptor "plugin" which should allow Mailman list members
to be loaded from a MySQL database, rather than just a Mailman
"pickle" file.
Provided as-is, and without warranty, this "plugin" may destroy your
server, soul, scalp, house, and life. Please use it with caution.
Kev Green, oRe Net.
http://www.orenet.co.uk/
----------------------------------------------------------------------
>Comment By: Kev Green (kyrian)
Date: 2005-05-31 19:57
Message:
Logged In: YES
user_id=99923
Folks,
Well, I've finally gotten around to releasing an update to
this thing, after a phone conversation with the client who
are using it, and I've incorporated a couple of cosmetic
fixes, fairly substantial changes to make the bounce
processing work properly (the ability to set people to
NOMAIL now exists, and real world testing is commencing
soon), and incorporated the flat vs. wide table archivecture
types with various bugfixes.
Main notes:
* It would be a good idea to change all your delivery_status
fields from VARCHAR(255) to INT(10) or similar, so that they
will work properly, and not bomb out on this new version
(they should be okay I think, but I'd advise the change).
* The missing-'AND' typo has been rectified.
Any suggestions and bugs should be sent to my sourceforge
account address, which ends up in the right place.
K.
----------------------------------------------------------------------
Comment By: Gergely EGERVARY (egervary)
Date: 2005-04-09 11:14
Message:
Logged In: YES
user_id=1255996
Thank you for your good work.
FYI: there's a missing "AND" in MysqlMemberships.py in line 494.
----------------------------------------------------------------------
Comment By: simboforge (simboforge)
Date: 2005-03-11 23:22
Message:
Logged In: YES
user_id=1226150
excellent. can you please give me a list of the files
modified from the original distro? grep sees six that grep
have msyql in them. thx
----------------------------------------------------------------------
Comment By: Kev Green (kyrian)
Date: 2005-03-11 22:56
Message:
Logged In: YES
user_id=99923
The flat file databases are unused when you put the MySQL adaptor in
place, and they are untouched (and indeed not deleted) by it, the MySQL
adaptor only queries the MySQL tables for membership information, without
trying to force you into using it fulltime by deleting anything, etc.
Once you unconfigure the MySQL adaptor, Mailman should revert back to
your existing flat file databases.
Of course, I could have missed something, etc. so do back up your flat file
databases before installing the MySQL adaptor, and then you can just
migrate back to them by restoring the backups.
Either way, you have come up with a good question for an FAQ on the SQL
adaptor :-)
K.
----------------------------------------------------------------------
Comment By: simboforge (simboforge)
Date: 2005-03-11 22:42
Message:
Logged In: YES
user_id=1226150
neat. just what i was looking for. i have a couple of live
lists running on version version 2.1.5. i am a bit leary
about unzipping this distrobution over the top of my working
mailman as i am not sure how to backup the existing flat
file databases. i would prefer to experiment with dropping
the adapter into my existing installation. any pointers as
to where to start? thx
----------------------------------------------------------------------
Comment By: Kev Green (kyrian)
Date: 2004-12-13 18:34
Message:
Logged In: YES
user_id=99923
Oh, btw. v1.57 hasn't been tested yet, so it might kill your
server, eat your dog, and stick your wife in the oven. Be
careful using it!
----------------------------------------------------------------------
Comment By: Kev Green (kyrian)
Date: 2004-12-13 18:33
Message:
Logged In: YES
user_id=99923
Version 1.57: 2004/12/13
* Merge in Daniel Shriver patch/code for a flat table
architecture.
[ Suggested by Kevin McCann <kmccann(at)bellanet.org>, but
I hadn't found time to do it myself... ]
* Add bugfix information from Jinhyok Heo
<novembre(a)NOSPAM.ournature.org>
* Add in mksqlmailman script from TheSin
<thesin(a)SPAMNOTHANKS.southofheaven.org>
* Follow Barry Warsaw's suggestion on delivery status timestamp.
----------------------------------------------------------------------
Comment By: Kev Green (kyrian)
Date: 2004-01-08 11:38
Message:
Logged In: YES
user_id=99923
Latest version incorporates automated generation of the necessary tables,
cleaner error reporting, and updated documentation.
----------------------------------------------------------------------
Comment By: Kev Green (kyrian)
Date: 2003-11-11 11:14
Message:
Logged In: YES
user_id=99923
Bit of an oops in version 1.49, 1.50 now uploaded, which should fix it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_i…
Bugs item #1212066, was opened at 2005-05-31 15:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1212066&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configuring/installing
Group: 2.1 beta
Status: Open
Resolution: None
Priority: 5
Submitted By: Anton R. Ivanov (arivanov)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1.6rc4 mailing list creation mail has no Date: header
Initial Comment:
This is cosmetic (mostly)
The mail with a subject:
Mailing list creation request for list LISTNAME
is sent without a Date: header which makes Mozilla and
other mail clients display it as sent on 1/01/1970
A.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1212066&group_…
Bugs item #1211922, was opened at 2005-05-31 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1211922&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configuring/installing
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Anton R. Ivanov (arivanov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect config load 2.1.5 up to 2.1.6rc4
Initial Comment:
This is observed in debian 2.1.5 package and in 2.1.6rc4
installed from source:
Custom header rules under Privacy Options/Spam filters
are lost if the URL
http://server/cgi-bin/mailman/admin/listname/privacy/spam
is accessed directly without being authenticated in
advance.
How to reproduce:
1. Enter some rules
2. Logout/Login view them to see if they are still there
3. Logout
3. Try to access
http://server/cgi-bin/mailman/admin/listname/privacy/spam
directly. Mailman asks for a password and after that the
rules are blank.
2.1.5 also loses them on a few more occasions when
navigating around the web interface. In either case the
custom antispam rules feature is unusable.
For more information see debian bug 309870
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309870
A.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1211922&group_…
Patches item #1210507, was opened at 2005-05-28 12:05
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: list administration
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to not respond to successful confirm command
Initial Comment:
Some people feel that the e-mail response to a
successful e-mail confirm command is unnecessary and
confusing. This patch to the 2.1.6rc4 base adds a
mm_cfg.py option to control the sending of the e-mail
reply to a successful confirm.
The patch adds
RESPOND_TO_SUCCESSFUL_CONFIRM = Yes
to Defaults.py.in, and code to cmd_confirm.py to test
this and not send the response in the case when it is a
successful confirm and RESPOND_TO_SUCCESSFUL_CONFIRM
has been set to No in mm_cfg.py.
Note that if you apply the patch to an already
configured existing installation, you need to patch
Defaults.py instead of Defaults.py.in, but presumably
you would only apply the patch if you were going to put
RESPOND_TO_SUCCESSFUL_CONFIRM = No
in mm_cfg.py anyway, so patching Defaults.py would not
be mandatory in this case.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2005-05-28 15:04
Message:
Logged In: YES
user_id=1123998
Updated patch - structurally different but functionally the same
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…
Patches item #1210507, was opened at 2005-05-28 12:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: list administration
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to not respond to successful confirm command
Initial Comment:
Some people feel that the e-mail response to a
successful e-mail confirm command is unnecessary and
confusing. This patch to the 2.1.6rc4 base adds a
mm_cfg.py option to control the sending of the e-mail
reply to a successful confirm.
The patch adds
RESPOND_TO_SUCCESSFUL_CONFIRM = Yes
to Defaults.py.in, and code to cmd_confirm.py to test
this and not send the response in the case when it is a
successful confirm and RESPOND_TO_SUCCESSFUL_CONFIRM
has been set to No in mm_cfg.py.
Note that if you apply the patch to an already
configured existing installation, you need to patch
Defaults.py instead of Defaults.py.in, but presumably
you would only apply the patch if you were going to put
RESPOND_TO_SUCCESSFUL_CONFIRM = No
in mm_cfg.py anyway, so patching Defaults.py would not
be mandatory in this case.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…
Bugs item #1208828, was opened at 2005-05-26 02:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1208828&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: bounce detection
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sub Zero (subzero5)
Assigned to: Nobody/Anonymous (nobody)
Summary: Message from InterScan Messaging Security Suite
Initial Comment:
I get a bounce from InterScan Messaging Security Suite
and the body of the returned message is like this
(between the quotes)
"****** Message from InterScan Messaging Security Suite
******
Sent <<< RCPT TO:<nonexistinguser(a)domain.dom>
Received >>> 550 5.1.1 <nonexistinguser(a)domain.dom>...
user unknown
Unable to deliver message to <vitel(a)vitel.com.tr>.
************************ End of message
**********************"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1208828&group_…
Patches item #1208685, was opened at 2005-05-25 15:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1208685&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: John Dennis (jdennis-redhat)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailmanctl report status
Initial Comment:
Mark's point about the presence of the pid and lock
files not being a definitive
metric of mailman health should not be ignored. You
really have to
ascertain the status of the process. If mailman is
abnormally aborting,
which is what started this thread, then there is a high
degree of
probably the lock files will be left behind and testing
them will give
false positives.
In the Red Hat mailman RPM's we've modified mailmanctl
so that it can be
asked the status of the mailman process as an
unprivledged user and
return the result as status to the shell as well as
printing a message.
Since mailmanctl knows how to locate the process and
communicate with
the process via signals it makes mailmanctl the optimal
reporter of
status. It was probably an oversight mailmanctl never
had this facility.
We have also integrated this with the mailman init.d
script so that one
can perform the standard "service mailman status"
command. The init.d
script depends on the exit status of "mailmanctl
status". These two
changes probably represent a more robust and standard
way to determine
status.
Two files are patched in this patch, mailmanctl and
mailman init.d script. Technically the init.d script
does not need to be modified to take advantage of the
mailmanctl status feature, but the two are really meant
to play together.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1208685&group_…