Mailman-Developers February 1999

mailman-developers@python.org

29 participants
49 discussions

by Greg Stein

small change request: remove that dang password-change dialog from every screen I don't see a need to have it on *every* screen. It seems awfully redundant, and just ends up cluttering the other screens. -g -- Greg Stein, http://www.lyra.org/

21 years, 11 months

Re: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?]

by J C Lawrence

On Sun, 21 Feb 1999 13:25:39 -0500 Ken Manheimer<klm(a)digicool.com> wrote: > [Christian tismer is having problems migrating a bunch of maillists > to the new version, specifically because of the skew in customized > (and even non-customized!) list web page templates. It brings up > what i think is a substantial question about the template mechanism. > I want to put the issue out there, see what the prevailing wisdom > is. Details below...] I share his concerns, and am running into a few similar problems with clients I'm deploying MailMan at. Further, while the template structure is useful, the ability to define complex nodes for the templates is not wonderful. eg When the HTML for the list introductory description (that gets inserted into the listinfo page) is non-trivial, is is an absolute bitch to edit and correct in the provided form. Getting http://www.kanga.nu/lists/listinfo/mud-dev/ to look right took almost an hour. It still isn't quite right, but I've given up trying to fix the last niggles figuring its "good enough". Note: The only editing I did on the template was on the archives section as I don't use pipermail. All the rest is via the template expansion. -- J C Lawrence Internet: claw(a)kanga.nu ----------(*) Internet: coder(a)kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

22 years

Re: [Mailman-Developers] msnbc mailman mention

by Alex Yu

At 02:42 AM 1999/2/28 -0500, Corbett J. Klempay wrote: >Hey, did you guys notice this MSNBC article mentioning Mailman? Big >http://www.msnbc.com/news/244979.asp Guest what, even Microsoft coders are using Linux + Xwin + emacs + egcs compiler to do their work. It is true!!! Linux owns! Alex

22 years

msnbc mailman mention

by Corbett J. Klempay

Hey, did you guys notice this MSNBC article mentioning Mailman? Big league! :) http://www.msnbc.com/news/244979.asp ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Work like you don't need the money, love like it's never going to hurt, and dance like no one is watching..." ------------------------------------------------------------------------------

22 years

[Fwd: Re: [Mailman-Users] Strange Problem.]

by Greg Stein

Harald Meland wrote: > > [Michael Quigley] > > > ----- The following addresses had permanent fatal errors ----- > > "|/d0/mailman/mail/wrapper post webmaster" > > (expanded from: webmaster(a)goingv.com) > > > > ----- Transcript of session follows ----- > > 554 "|/d0/mailman/mail/wrapper post webmaster"... unknown mailer error 1 > > This indicates that the "wrapper" binary or something exec()d by it, > exit()ed with a status 1 (indicating that something failed). > > The first thing to suspect is that "wrapper" is being run under the > wrong gid. If that is the case, it tries logging this to syslog. The > fix is either to reconfigure mailman with the "--with-mail-gid" option > (and then rebuild and reinstall), or else configure your MTA to run > the pipe under the correct gid. This brings up an interesting idea: have the wrapper use different exit codes based on why it punted. That way, a simple examination of the maillog will tell you what happened. Cheers, -g -- Greg Stein, http://www.lyra.org/

22 years

mailman error

by Gergely Madarasz

Hello! What does this mean ? Feb 21 00:47:29 1999 mailcmd: Traceback (innermost last): mailcmd: File "/var/lib/mailman/scripts/mailcmd", line 52, in ? mailcmd: list.ParseMailCommands() mailcmd: File "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 86, in ParseMailCommands mailcmd: sender = string.lower(mail.GetSender()) mailcmd: File "/usr/lib/mailman/Mailman/Message.py", line 122, in GetSender mailcmd: return string.lower(mail_address) mailcmd: TypeError : read-only buffer, None The mail command that triggered this message was a simple subscribe request... with a bad From: header, though From: Claudio Granatiero <@.> Btw wouldn't it be nice if these tracebacks printed out the values of the variables, too ? :) -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/

22 years

Re: [Mailman-Developers] Possible bug in 1.0b8

by Harald Meland

[Harald Meland] > Please bear in mind that this is the first time I'm trying to do any > CGI-related programming at all, but I still _think_ this patch is good > (from reading the CGI/1.1 spec, and testing quickly that it doesn't > break my web interface). I was slightly wrong about the patch being perfectly good -- the Utils.CGIpath() function would, if both of the "proper" methods for getting at the path failed, fall back to ("/mailman/admin/" + list_name), regardless of which CGI script called it. This would, obviously, be wrong if called from e.g. "admindb". It could also be argued that referencing the (hopefully defined) global variable list_name from CGIpath() is unnecessarily risky. Below is a patch (against current CVS) which fixes these problems by operating in a manner very similar to os.environ.get(), i.e. letting the caller supply the complete fallback value. [ I'm not really sure that putting a pretty special-purpose function like CGIpath() into the generic Utils module is the Right Thing -- but I couldn't see anywhere else where it would fit better. ] Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/24 20:26:00 @@ -664,3 +664,22 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env, fallback=None): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. + + Optional second argument `fallback' (default `None') is returned if + both of the above methods fail. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return fallback Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/24 20:26:01 @@ -123,8 +123,8 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ, + '/mailman/admin/' + list_name), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/24 20:26:01 @@ -112,8 +112,8 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ, + '/mailman/admindb/' + list_name), 'message' : message, }) print text -- Harald

22 years

Re: [Mailman-Developers] Possible bug in 1.0b8

by Harald Meland

[Liam Kirsher] > I found the problelm in > > Cgi/admindb.py, line 116 > > the reference to /mailman/admindb/ was a problem. > I think the "mailman" part should be gotten from the DEFAULT_URL, > perhaps? I don't think that DEFAULT_URL has anything to do with this problem -- the fix is rather related to not depending on the not-really-standard (I think) REQUEST_URI environment variable. Please bear in mind that this is the first time I'm trying to do any CGI-related programming at all, but I still _think_ this patch is good (from reading the CGI/1.1 spec, and testing quickly that it doesn't break my web interface). Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/22 17:16:37 @@ -664,3 +664,20 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. If that fails, + too, fall back to a hardcoded common case. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return ('/mailman/admin/' + list_name) Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/22 17:16:38 @@ -123,8 +123,7 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/22 17:16:38 @@ -112,8 +112,7 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ), 'message' : message, }) print text -- Harald

22 years

CVS Tree???? - What happened to the Cgi directory???

by Jeff Hahn

went to update my local copy No Cgi directory? Therefore empty cgi-bin directory after installation Any ideas? -Jeff

22 years

[Fwd: Re: [Mailman-Users] Upgrade script for old databases?]

by Ken Manheimer

[Christian tismer is having problems migrating a bunch of maillists to the new version, specifically because of the skew in customized (and even non-customized!) list web page templates. It brings up what i think is a substantial question about the template mechanism. I want to put the issue out there, see what the prevailing wisdom is. Details below...] -------- Original Message -------- Subject: Re: [Mailman-Users] Upgrade script for old databases? Date: Sun, 21 Feb 1999 10:19:46 -0500 From: Ken Manheimer <klm(a)digicool.com> Organization: Digital Creations, Inc. To: Christian Tismer <tismer(a)appliedbiometrics.com> CC: bwarsaw(a)python.org, klm(a)digicool.com Christian wrote: > Exactly. But extraction is not so much my problem, it is much more > how to move to all the new structures and layouts without getting > my customers involved. Ah - the customized-per-list listinfo template, for instance. I'm afraid you're right - the way that mailman provides for customization is not at all amenable to reconciling with new site templates. It's doubly bad because each list gets its own copy of the site templates when the list is created, so it gets locked in even when the list administrator doesn't tailor their templates from the site standard. Fixing this latter would not be hard, but it still wouldn't address the issue of tracking refinements in the site standard when the list has a divergent version. I imagine the solution there is to allow list managers only parameterized customization of their templates - something that dtml would make easier - but that, itself, is a tricky track. Sigh. > At least that, and if possible some more. I can write this myself, > and was just hoping that somebody had done so already. The HTML > is a different story... Sorry - i certainly haven't thought of a general solution, so i hadn't implemented anything... > My problem is that I have [a bunch of]u lists which are used by > my customers on starship.skyport.net, and I want to avoid > masses of conversation and support, when I try to move this to > mailman 1.0b7 or such. > The situation is even worse, since some changed the html > layouts a little, and the new layout is very different, also > the attribute names of the inserted variables have changed. > That's quite a lot of work, and if somebody had done so already, > I could use it as a starter and put more automation in, > but my time is so limited. > > I have a real migration problem here... > > Hmm. A mailinglist is a structure. Our (my) problem is that the > structure is no clean structure, but contains implementation > details. If there were another level of abstraction, like, say, > an XML DTD which defines what a Mailing list is, I could > do the move much easier. > > Sigh - I fear I have to do it by hand. Sorry - i agree that it's a problem. In fact, my inclination is to think that the freedom that list-customizable templates offers is not worth the migration issues that it presents. (I do know that some customizability is important - for instance, someone using mailman at cnri needed to simplify the listinfo page to basically just be a subscription page, without the archive and roster links, so offering parameters to turn off sections would probably be the right way to head. Something that worries me about this is that we've already established the current setup as the precedent, but i'm wondering whether it's worth rethinking. Christian, i'd like to bring the mailman cabal in on the issue - would it be ok if i forwarded this message to them? Ken

22 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers February 1999