Wow. I appreciate the in-depth comments.
Earl Hood (earl(_at_)earlhood(_dot_)com) wrote:
* The formail path problem you mention is a bug. It is now
bug #5437:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5437&group_id=1968
* The answer to your $time_fmt comment is that the catch archive is
out of the main loop, so $time_fmt does not contain an applicable
value, hence the hard-coded value. However, since one can
technically define lists.def options for the catch archive, it
would be reasonable to check if there is a period setting.
It is now bug #5439:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5439&group_id=1968
yay, thank you.
* I wish the procmail maintainers would fix version 3.22 and
piping-out-of-memory problem. I guess I need to consider if applying
some of the work-arounds should be put into mharc, as you have done
with yout mk-procmailrc patch.
I'm not holding my breath for procmail 3.23; I've heard no rumor that
Philip has managed to dig his way out of this "real-life" thing that
swallowed him...
Also, I think there is something with older versions of namazu that
may cause problems (i.e. unexpected crashes during index creation
-- a reason I had to add namazu_cleanup() in web-archive). Therefore,
users should upgrade to 2.0.12, or later, if possible.
I do not know if it was ever determined what caused mknmz to
fail, but it was pain since search indexes would fail to get updated.
I have not encountered this problem with namazu 2.0.12.
That's good to know. the NetBSD package system applied more
netbsd-specific patches than I'm comfortable mucking around with, but if
I start seeing problems, I will attempt to overcome that discomfort.
* Re: Note for NetBSD Package System users: I'm not familiar with
how NetBSD packages applications, so it would be nice if they at
least provided an "unstable" package (similiar to how Debian
does things) for those that need a newer version.
They've got a -current branch of OS development which can have
newer versions of the packages than the releases, which got MHonArc
2.6.8 eight days ago.
But the packages in general tend to lag cutting-edge by a great deal;
it's the downside of a controlled, surprisingly-stable, system for making
third-party software very portable across NetBSD's eight zillion ports
(okay, that's an exaggeration. Fifty-nine platforms, twelve of which are
experimental. But still lots of platforms, which is one of the stated
reasons for keeping the package system as controlled as it is). I don't
have a good sense as to how many people use -current vs. how many stick
only with the released versions.
Since MHonArc development and releases are done under RedHat linux,
I now provide RPM releases directly. If there is a way to build
other packages for other OSs under linux, I will consider providing
alternate packages directly.
Interpreted software tends to be pretty straightforward to maintain in
the package system, as once the interpreter is ported, the scripts tend
to install with no change necessary unless the scripts rely on
architecture-dependant features.
In MHonArc's case, it looks like the recent MHonArc update in -current
pkgsrc was pretty trivial:
http://mail-index.netbsd.org/netbsd-bugs/2003/09/11/0010.html
the previous update brought it up to 2.6.6 and occurred ten days after
it was released. But 2.6.7 was skipped altogether. That's about par
for interpreted packages, I think.
I don't know how easy it would be to verify updates without a netbsd
system on-hand.
* Re: Populating lib/lists.def: It appears to not be clear in your
comments, but mk-procmailrc already does key off List-Post when
setting addresses via the Address: lists.def option.
I didn't know that. That's great. (Given the vagaries of my listowners
list-addressing & their vanity domains, it's still not the right choice
for me -- but I don't think my case is very common.)
Your comments about cross-posting must be specific to mailman
since mharc is designed to handle it (the reason for the ":c"
in procmail recipies). However, if you are refering to the case
where a message could have different headers add to it (like List-*
headers) when cross-posting, then mharc currently does not handle
that as one would desire. The first message that comes in will win,
therefore, an archive for one list may have a message with List-*
headers of another list.
Therefore, I can see a reason for disabling the message-id cache.
*nod* yes, that was largely my concern. And it allows me to rely
primarily on the List-Post header, which is largely under my control,
rather than any of the other address-related headers which tend to vary
as the listowners get creative.
Maybe I can make this configurable option. Therefore, for your
usage case, you can easily disable the cache and then use
the following in lists.def for matching a given list:
Name: listname
Procmail-Condition: * ^List-Post:.*:listname@
Final: 1
Adding the Final is mainly a performance gain, but if not present,
it just means that each message will always be tested against all
list matching rules. I think your patch to drop the ":c" is
not needed since you can achieve the same effect via lists.def.
*nod* I see I failed to read the perldoc closely enough; I suppose I
saw the -final-dest flag and stopped thinking. Thank you.
* I'm not familiar with mailman's "bin/list_lists -b", but it may be
possible to write a simple Perl script that auto-generates a template
mharc lists.def file based on its output.
Yeah, this should be pretty straightforward. And actually, the -b flag
suppresses the description, which if things are going to be automated,
could be used in lists.def, too. The default output of list_lists looks
something like:
Art-projects - [no description available]
beacon-l - Folks interested in the CoM / eVille homing beacon
/ art
Dnd-l - [no description available]
Efund-l - [no description available]
junkmail-l - Anything disgusting or funny, under 20k.
Yes, centered. And the descriptions are truncated, sometime after they'd
hit 80 columns but truncated at some point nonetheless. Out of sheer
laziness I decided to use the -b flag, which outputs listnames one per
line, not centered, no description.
A more robust script would
allow one to update lists.def as new lists are created by mailman.
That would fit in with Mailman's architecture well; at list-creation
time Mailman's aliases file is updated similarly.
I don't know how much demand there is for this sort of thing, tho.
* Your desire to put mbox files under the html directory was requested
by someone else some time back, I believe. I believe that user
found an alternative acceptable solution.
I think the idea of having more flexibility in the placement of
mbox files (and even html archives) on a per list basis can be
a useful, and very powerful, feature. Such a feature could be
driven by lists.def. For example:
Name: listname
Mbox-Archive-Path: /path/to/directory/for/listname/mbox/files
Html-Archive-Path: /path/to/directory/for/listname/html/archives
...
Such changes would require changes to mk-procmailrc so procmail
rules are defined properly, and there must be changes to web-archive
(especially when doing file deletions on a rebuild).
Putting the actual mboxes in the html directories makes me jumpy. As
far as I'm concerned, the mboxes are Important Data but the html files
are easily regenerated and therefore expendable. So putting important
data in a filestructure designed for expendable data just doesn't sit
right with me.
This may just be a personal problem for me. :)
Anyway, I was reasonably happy with scattering symlinks everywhere.
* Couldn't your symlinks to the mbox files be more like?:
$HTML_DIR/listname/mbox -> $MBOX_DIR/listname
I.e. In Perl code:
symlink("$MBOX_DIR/$list","$htmldir/mbox")
Wouldn't this disable the clunky URLs?:
http://example.com/mailman/private/listname/mbox/2003-09
Sure. It would also require a change to web-archive, because as
written, it expects $mbox_url to be
join('/', $MBOX_URL, $list, $mon);
...with the month right after the listname. I was aiming for not making
source code changes where I could get by just making symlinks and
configuration changes.
* Re: Stylesheet ...: You may want to use the Tip mentioned in
the mharc installation notes about how to handle custom layout
changes. The Tip is mentioned under "Archive Customizations" in
the installation doc. I am considering making the Tip a default
behavior of mharc. I.e. Change the MHA_MRC config.sh variable to
default to $SW_ROOT/lib/default.mrc, with the guarantee that mharc
will never make changes to it, only to common.mrc.
This method makes dealing with mharc upgrades much easier and
it isolates local customizations from mharc defaults.
Therefore, all of editing resource recommendations would be done
in default.mrc.in and not in common.mrc.in.
oo. I like that.
I think when I read the tip the first time I was expecting to be making
only very small changes, and didn't think want to reproduce all the
unchanged lines of, say, <IdxPgBegin> just to change a line or two. But
that was before I actually sat down and started making changes...which
turned out to be more extensive than I expected.
* Your web-archive patches to support author and subject indexes
in top indexes is something I considered. I.e. Some more
generalized, MHonArc-ish way to customize top (and the all-lists)
index pages.
I should note that namazu makes the use of author and subject indexes
not that important (and I personally have found little use for them).
First, you will notice that the default navigation layout of message
pages provides quick links to get a list of other messages from
the same author and to get a list of messages with the same subject.
Of course, the usefulness of the author link may be minimal if
employing address obfsucation techniques.
*nod* they're largely redundant for my installation. I added them
because the time I spent on the customization is far less than the time
I would have spent answering user-email about "Where'd the author sort
go!?"
* The mbox-month-pack command does support a -msgsep option (it
appears I failed to document it). For example:
mbox-month-pach -msgsep '^From \S+.*\d+:\d+:\d+' ...
This can probably be used to avoid any pre-process steps. You should
also look at the MSGSEP resource setting in common.mrc.
Ahh, that is a good regexp to keep track of. :)
There appears to be an implication that the mailman developers are
somewhat resistant to contributed changes. Is this your impression?
I wouldn't go exactly that far.
They've got particular patterns of usage they're explicitly looking to
support, and they are unwilling to incorporate changes that might
compromise the speed and ease-of-use for those particular patterns.
This means they've sacrificed some flexibility in return for the ability
to better serve their target users. I'm just not exactly their target
user.
Private archives and external archivers, for instance, they've explicitly
called out as less important than speed-of-access for public archives.
They rejected a patch that would have been of great benefit to people
combining private archives with external archivers. I'm not convinced
they gave that particular approach sufficient attention, as it was
trivial for me to implement a compromise change that did what the
original requestor wanted but still left functionality and speed entirely
unchanged for people without private archives.
And those who've reported significant performance degradation for
archiving in the recent release seem to be out of luck, as well.
So, they've made it clear that outliers like me aren't going to get a
whole lot of sympathy from them. I'm disappointed, but within their
particular set of priorities, they seem willing to accept contributions.
sev, who will probably send the integration document to the mailman
lists *anyway*, but is not incredibly optimistic about the
reception it might receive
--
*** sev(_at_)byz(_dot_)org can also be found at http://www.byz.org/~sev ***
"There are no dangerous thoughts; thinking itself is dangerous."
-- Hannah Arendt
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHARC-USERS
