> We're definitely "talking at cross-purposes".
> Sometimes the person responsible for creating the FreeBSD port for a
> particular program will pipe up and explain the why's and wherefore's of
> how s/he chose to make his install template and might even explain its
> idiosyncrasies. If a user detects an install problem like this, and the
> port maintainer helps to fix it, the fixes get funneled back into the
> port, thus making it better.
Seems like the person responsible for the not-part-of-Mailman-and-therefore-
completely-unknown-to-the-rest-of-us add-on installation gunge for
FreeBSD is the right person to ask, then; hopefully they left their
tracks on some added file?...
After failing to install via package and by compiling the source on a
system at work, I realized I could test installing 2.0beta5 on a FreeBSD
server at home. I still can't create a new list using bin/newlist; I get
the now familiar result:
Traceback (innermost last):
File "./bin/newlist", line 37, in ?
ImportError: No module named paths
What does this mean?
I'm running FreeBSD 3.4 on both servers. The one at work is behind a
dorporate firewall, so I can't use the ports collection. The one at home
(whose results are above) can use the ports collection in the normal
manner - compiling/installing/resolving dependencies right off the net.
Installing on the server at home, I noticed a couple of interesting
-- The install program did create user and group mailman, but I couldn't
su to user mailman after the install was completed. Is this by design? Are
administrators no longer supposed to su to user mailman to do things like
create new lists? The passwd file listed the home directory as "-s",
whatever that means.
-- The install directly off the net placed the files in a subdir off of
/usr/ports/distfiles; no files were copied to /home/mailman. Do we usually
copy the files there manually when done with the install?
-- Bottom line, I'm still uncertain how to actually get mailman working
properly. The automatic install from the ports collection didn't even seem
to work properly. What's necessary to resolve the "No Module Named Paths"
Yes, the paths are all the same. All of the home and data directories
were moved to the new machine using rsync -alz to maintain the
permissions, ownership, and directory structure. I think the
restricted hardlinks may be the problem, but I am still trying to
figure out how to turn them off.
On Tue, 29 Aug 2000, Ron Jarrell wrote:
> At 11:35 AM 8/29/00 -0600, you wrote:
> >I moved my entire system to a new machine yesterday and now I get error
> >like this whenever trying to use admin or admindb.
> >I have tried everything I can think of. Please help. I have several
> >list administrators chompping at the bit.
> >The new system is Mandrake-Linux 7.1, I did a clean configure, make and
> >install of mailman after rsyncing the home directory to the new machine.
> Are the new lists in the same path as the old lists, but on the new machine?
> The pathnames are coded into the list databases. It looks like it's trying to
> do hardlinks across filesystems...
Content-Type: text/html; name="unnamed"
At 12:33 PM 8/29/00 +0200, nancy.aharpour(a)libero.it wrote:
>Why I can't subscribe anyone by web page to the list that I've just
>I can see from the subscribe log that the request in pending but I don't
>know how to delivery it.
Did you use the admin page, (whatever/mailman/admin/LISTNAME/members),
or did you go to the listinfo pages (whatever/mailman/listinfo/LISTNAME) and
subscribe them from there? If you used the listinfo page, then they're probably,
if you took the defaults, waiting on confirmation from the subscriber to finish
the signup process.
Or, if you set it to moderator only, then they're waiting on *you* to approve
them, and they probably have mail telling them they're waiting on the moderator
to approve their subscription. You can tell that from the admindb page.
(Those are URLs, of course, with "whatever" being your mailman host, and
LISTNAME being whatever you called your list. For foo.com, and list
"demolist", it'd be http://foo.com/mailman/admindb/demolist)
As an admin, subscribe people via the admin page, which just goes and
adds them to the list. The only reason an admin would use the member page
is if they wanted to be able to explicitly set the password to something
Anyone else have problems with the admin pages randomly not responding
for some lists? For some reason, every so often the admin page link does
not work for various lists. The problem floats around from list to list
and usually goes away after a day or so. At first I thought the list had
been corrupted, but this does not appear to be the case. I can remove
the list entirely, restart the computer, create a new list with the same
name an the problem persists. It never seems to happen to more than one
list at a time. (1/15 at the moment)
Anyone else have similar experiences or ideas? Thanks..
. . . . . . . . . . .
Music and Technology
Virginia Tech School of the Arts
> Does the latest mailman still require on-disk cookies? On my normal web
> browser I don't allow cookies to be written to disk, but I've got no
> objections to having session cookies and such. Thanks,
I don't think it ever required "on-disk" cookies (unless there's something
that implies that I don't know about) but the latest versions use
"session" cookies (i.e. only valid for this browser session)
and I believe the expiry time has been removed too.
> Assuming you're not getting errors in your log files, it's probably a
> cookie problem. In fact, that's strongly implied by the fact that
> creating a new list with the same name. Does the problem go away if
> you exit the browser and start it up again? (This only works with
> the most recent beta, which I notice you're running, because the new
> beta makes the cookie a "this session only" cookie). There were a
> *lot* of cookie maintenance changes fairly recently.
Look out for broken browsers. I recently got Opera to agree that 4.0
has a bug where it can save temporary cookies to disc as if they were
permanent ones set to expire in the future. On re-starting Opera it
re-supplies those temporary cookies back to the site.
> -----Original Message-----
> From: Ron Jarrell [mailto:firstname.lastname@example.org]
> Sent: Monday, August 28, 2000 5:57 PM
> To: mailman-users(a)python.org; mdunston(a)music.vt.edu
> Subject: Re: [Mailman-Users] list admin server doesn't always respond?
> Assuming you're not getting errors in your log files, it's probably
> a cookie problem. In fact, that's strongly implied by the fact that
> creating a new list with the same name. Does the problem go
> away if you
> exit the browser and start it up again? (This only works
> with the most
> recent beta, which I notice you're running, because the new beta makes
> the cookie a "this session only" cookie). There were a *lot*
Does the latest mailman still require on-disk cookies? On my normal web
browser I don't allow cookies to be written to disk, but I've got no
objections to having session cookies and such. Thanks,
> > One can always change Archiver.py for one's installation, I suppose.
> Yeah, works for now. Of course, the next upgrade will blow it away...
A useful hint: if you make a CVS tree, then you can change your
local file and 99% of the time just forget about it. I finally
got religion and did this, and it turns out that, if Barry changes
a file I've changed, most of the time CVS merges it correctly
and automatically. For a change like this, it will certainly
That has the other advantage of being on the bleeding edge if you
want to (you can always check out the Last Tarball Version if you
want using symbolic tags)