Mailman 3 October 1998 - Mailman-Developers

New version of my patches
by Balazs Nagy Oct. 20, 1998

Oct. 20, 1998

Hiyas, My new release of my patches (admin commands + 'set digest' command fix, cgi-ext, sendmail/qmail using) are available at http://www.kva.hu/~mailman/patches or http://www.kva.hu/~mailman/mailman-patches.{tar.bz|tgz} -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8

1 0

possible bug in b5
by Corbett J. Klempay Oct. 18, 1998

Oct. 18, 1998

I'm not sure if this is known/already fixed or what... I created a list for another guy...and he never went in to put in the stuff like the list description and all...I think he went into the admin section once to mass subscribe a few people and that was it... When we went to the main listinfo page, the new list was not listed, even though it was a public list. I went to the General Options page and edited the preferred hostname field and hit submit. After doing this, the new list was listed on the main public list page (with a blank short description, as I still haven't touched any of the other General Options fields). Anyone else seen this before? It's not a biggie; and it's now fixed here... ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Keep your faith in all beautiful things; in the sun when it is hidden, in the Spring when it is gone." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------

3 2

Mailman exceptions, need help please
by Tomas Fasth Oct. 18, 1998

Oct. 18, 1998

Hi. I'm somewhat lost here, therefore the call for help. I have an experiment installation of Mailman. It started out as 1.0b5 but is now reflecting the cvs head of mailman sources at the cvs.python.org:/projects/cvsroot repository. At some point while trying to find an alternative for using aliases in sendmail (by defining a mailer and a dispatch script), the post and deliver of mailman started to report exceptions. I did a clean sweep (I think) and reinstalled it several times. I also switched between python 1.5 and 1.5.1. Nothing helped. Here's what is reported in the error file when running python 1.5: Oct 16 21:45:23 1998 post: Traceback (innermost last): post: File "/home/mailman/scripts/post", line 40, in ? post: LogStdErr("error", "post") post: File "/home/mailman/Mailman/Logging/Utils.py", line 41, in LogStdErr post: multi = MultiLogger(sys.__stdout__, sys.stderr) post: AttributeError : __stdout__ Oct 16 21:45:29 1998 deliver: Traceback (innermost last): deliver: File "/home/mailman/scripts/deliver", line 41, in ? deliver: LogStdErr("error", "deliver") deliver: File "/home/mailman/Mailman/Logging/Utils.py", line 41, in LogStdErr deliver: multi = MultiLogger(sys.__stdout__, sys.stderr) deliver: AttributeError : __stdout__ Apparently this has something to do with an incompatibility between python 1.5 and 1.5.1. Here's what is reported in the error file when running python 1.5.1: Oct 16 21:48:41 1998 deliver (child): Traceback (innermost last): deliver (child): File "/home/mailman/scripts/deliver", line 154, in ? deliver (child): main() deliver (child): File "/home/mailman/scripts/deliver", line 49, in main deliver (child): do_child() deliver (child): File "/home/mailman/scripts/deliver", line 57, in do_child deliver (child): spawns = string.atol(sys.stdin.readline()[:-1]) deliver (child): ValueError : empty string for atol() This is the one I'm lost with. The deliver script is put into action in ~mailman/Mailman/Deliver.py by calling os.popen(). There seem to be a problem using that pipe. What's written in one end don't seem to show up in the other end. Is this a known problem that can occur in some circumstances (possibly python generic)? Any help would be much appreciated. Thanks. --tomas

1 0

Functional design issue - optional passwords
by John Evershed Oct. 17, 1998

Oct. 17, 1998

Why not simplify the unsubscription process so that it can not only be easily be done by forgetful users but also by dumb agents? Most mailing lists allow a simple UNSUBSCRIBE in either subject or body to trigger an unsubscription confirmation message being sent to the apparent user, with a random token which must be returned in the reply. This could be the default mailman behaviour when a password is omitted. A lot of people in the mailing list community obviously think that the mail unsubscription process should be both simple and standard - eg the RFC authors who proposed the new mailing list headers such as "List-Unsubscribe: <mailto:list-request@domain?subject=unsubscribe>".

2 1

lengthen default ADMIN_COOKIE_LIFE?
by Ken Manheimer Oct. 16, 1998

Oct. 16, 1998

I'm coming to consider that the length of the admin-pages cookie (ADMIN_COOKIE_LIFE) is too short. I'm considering extending the default life from 20 minutes to one hour. Alternately, i'm considering having the life of the cookie "refreshed" by the more moderate (20 minute) amount every time it's exercised - though i don't know about that part of cookie functionality, and don't know how complicated that would be. Seems like the latter would be better, if it's fairly straightforward to do. I do think it's incoveniently brief as it is. Thoughts? Ken

2 1

Changing admin address for "umbrella" list subscribers
by Ken Manheimer Oct. 15, 1998

Oct. 15, 1998

A while back i implemented a mailman feature to facilitate having "umbrella" lists to which other lists could be subscribed. I would like to change it slightly, and want to see if i'd be messing anybody up with the change. I'm not even sure if anybody but me uses the feature, so first i'll explain what it's about, and then i'll explain the problem. The idea is to enable maillists that are composed of only other maillists, as "subscribers". That way, announcements of interest to groups of lists could be sent to the encompassing list. This may sound peculiar, but it actually makes sense in the context of, for example, activities that have regional groups doing their regional thing, but also occasionally collecting together for, eg, national conclaves, or for discussions of common issues across the regions, etc. (In fact, i'm establishing a network of lists for people who do something i'm part of, contact improvisation, and this arrangement looks really pretty good for us.) The only special provision i had to make for this arrangment is an admin setting so that the members administrative stuff, like the monthly password reminders, are _not_ posted to the subscribed lists, but to their administrators. I created the 'reminders_to_admins' option, and set it so that the reminders would go to the 'list-admin(a)host.domain' account, rather than 'list(a)host.domain'. (I'm pretty sure this was pre 1.0b4, so it's been there for a while, probably unnoticed by most people.) The problem is that it may be that '-owner' is a more prevalent suffix for list administrator addresses than '-admin'. At least, that's what makelist.com seems to use, and from my probing they don't seem to support the '-admin' alias, while the policy for mailman is to support both. So i'm considering changing the option to go to '-owner' address instead of '-admin', but before i do that i wanted to find out whether (1) anyone already depends on the '-admin' option, and (2) whether anyone has objections to making the switch, in any case. (We could add *another* option to designate the suffix, but that doesn't strike me as a good solution - we'd be better off striving for some standard, than encouraging fragmentation here. What good would one choice or another be if some of the subscriber lists within the umbrella have one and some have the other?) Any clear feelings, one way or the other, from anyone? I plan on making the change within the next few days, but can still be dissuaded by solid arguments... Ken Manheimer klm(a)python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # <http://www.python.org/psa/>. #

2 1

Re: [Mailman-Developers] Alert to the cvs maintainer: another case of permission denial
by Tomas Fasth Oct. 15, 1998

Oct. 15, 1998

-----Original Message----- From: Ken Manheimer <klm(a)cnri.reston.va.us> To: Tomas Fasth <tomas(a)euronetics.se> Cc: Mailman-Developers(a)python.org <Mailman-Developers(a)python.org> Date: den 14 oktober 1998 20:52 Subject: Re: [Mailman-Developers] Alert to the cvs maintainer: another case of permission denial >On Wed, 14 Oct 1998, Tomas Fasth wrote: > >> I'm using :pserver:mailmancvs@cvs.python.org:/projects/cvsroot as root. >> Issuing a cvs update resulted in the following complaint: >> >> >cvs server: failed to create lock directory in repository >> `/projects/cvsroot/mailman/doc/IPC7': >Permission denied >> >cvs server: failed to obtain dir lock in repository >> `/projects/cvsroot/mailman/doc/IPC7' >> >cvs [server aborted]: read lock failed - giving up >> >> Do you need some assistance in hunting this problem down? > >The CVS guy is snagged by meetings during the day today - but he should >be able to tackle this one soon. Is the CVS guy on this list? Just got another complaint: U templates/help.txt cvs server: cannot open /projects/cvsroot/mailman/templates/reenable.txt,v: Permission denied cvs server: cannot open /projects/cvsroot/mailman/templates/reenable.txt,v: Permission denied cvs server: templates/reenable.txt is no longer in the repository The problem seems to occur when active developers add new files to the repository, possibly in combination with repository mirroring. The "cvs [server aborted]: read lock failed - giving up" have the potential of leaving the mailman source tree in an inconsistent state. --Tomas

2 1

Alert to the cvs maintainer: another case of permission denial
by Tomas Fasth Oct. 14, 1998

Oct. 14, 1998

I'm using :pserver:mailmancvs@cvs.python.org:/projects/cvsroot as root. Issuing a cvs update resulted in the following complaint: >cvs server: failed to create lock directory in repository `/projects/cvsroot/mailman/doc/IPC7': >Permission denied >cvs server: failed to obtain dir lock in repository `/projects/cvsroot/mailman/doc/IPC7' >cvs [server aborted]: read lock failed - giving up Do you need some assistance in hunting this problem down? tomas

2 1

tempfile bug or doc bug
by Scott Oct. 14, 1998

Oct. 14, 1998

the docs to tempfile state that: Warning: if a Unix process uses mktemp(), then calls fork() and both parent and child continue to use mktemp(), the processes will generate conflicting temporary names. To resolve this, the child process should assign None to template, to force recomputing the default on the next call to mktemp(). So I have a unix process (part of mailman) that forks, and can fork quite a bit, the parent process *never* calls mktemp, but the child processes all do, and i have darn good evidence of generation of duplicate file names by mktemp() under these circumstances. i suggest that we either fix the docs to mktemp to include this circumstance as an exception or make mktemp() not generate duplicates under these circumstances. scott

2 2

Re: [Mailman-Developers] CVS error + latest mailman-cmdhandler.patch
by Tomas Fasth Oct. 12, 1998

Oct. 12, 1998

-----Original Message----- From: Balazs Nagy <julian7(a)kva.hu> To: mailman-developers(a)python.org <mailman-developers(a)python.org> Date: den 12 oktober 1998 11:46 Subject: [Mailman-Developers] CVS error + latest mailman-cmdhandler.patch >Hiyas, > >There's an error in anon cvs: > >cvs server: cannot open /projects/cvsroot/mailman/templates/help.txt,v: >Permission denied >cvs server: nothing known about mailman/templates/help.txt Despite making changes as Barry was advising, the problem persist. Someone might have to take a look at the repository file permission settings. A fresh ckeckout will not pull down the help.txt file. tomas

3 2