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/
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...
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
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..."
------------------------------------------------------------------------------
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/
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/
[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
[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
[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