Re: perl 5.22 incompatibility

Following up, almost all the problems were fixed in 2.6.19. The remaining ones appear to be these, and are now patched into the Debian package. --- mhonarc-2.6.19.orig/lib/mhopt.pl +++ mhonarc-2.6.19/lib/mhopt.pl @@ -865,7 +865,7 @@ sub update_data_2_1_to_later { no warnings qw(deprecated);

perl 5.22 incompatibility

Today I am wearing my Debian Developer hat. Some longstanding Perl warnings in mhonarc have finally graduated into failure. There is a patch that appears to fix the problem. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816638 https://rt.cpan.org/Public/Bug/Display.html?id=76857 I'm planning

suppressing perl warnings

I've decided to ship hkoba's deprecation patch with Debian as of today. This will automatically propagate to quite a few Linux distributions with time. Please speak up if you think this is a terrible idea. http://savannah.nongnu.org/bugs/?32987 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7036

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #10, bug #20142 (project mhonarc): I should also mention the Tamil problem went away by itself (I think it turned out to be a weird browser bug or something like that) ___ Reply to this item at:

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #9, bug #20142 (project mhonarc): I've added about 500 examples of From fields containing backslashes - all this data is within the last two weeks. Since by necessity this field contains email addresses, I recommend deleting the dataset when finished. It is very easy to regenera

[bug #20142] strip backslash in rfc822 From: field

Additional Item Attachment, bug #20142 (project mhonarc): File name: data.gzSize:5 KB ___ Reply to this item at: ___ Messag

PyLucene example for mhonarc

Hi all, A while ago Earl asked if we'd be willing to share the code driving the search feature for The Mail Archive (mail-archive.com). I've gone ahead and put the relevant source code online. That's the good news. The bad news is you won't be able to just grab this code and add search to a mhona

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #6, bug #20142 (project mhonarc): Note to self: check if this patch is a possible cause of the $SUBJECT$ $SUSBJECTNA$ weirdness with Tamil. http://www.mail-archive.com/mhonarc-us...@mhonarc.org/msg01387.html ___ Reply t

[bug #18112] produces broken links

Follow-up Comment #3, bug #18112 (project mhonarc): Note to self - here's a particularly strong example. Might be breaking for two separate reasons. http://www.mail-archive.com/pymol-us...@lists.sourceforge.net/msg06881.html ___ Reply to

[bug #17563] mhonarc trashes malformed HTML

Follow-up Comment #3, bug #17563 (project mhonarc): ACK ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.nongnu.org/ -

Re: RFC 5064 Archived-At header

>Will someone provide some real use case scenarios of how the >archived-at URL gets used by a message receipient. If I have >the message locally, do I care where it is archived? It's handy if you are writing a blog. For example, Linux Weekly News reports on the Linux Kernel mailing list. They quo

Re: [bug #20142] strip backslash in rfc822 From: field

Ah, now I understand. This is the right patch. # diff -u /var/tmp/mhutil.pl /usr/share/mhonarc/mhutil.pl --- /var/tmp/mhutil.pl 2007-10-09 20:30:36.0 -0700 +++ /usr/share/mhonarc/mhutil.pl2007-10-09 22:05:59.0 -0700 @@ -177,6 +177,7 @@ - Hide quoted text - next if

Re: [bug #20142] strip backslash in rfc822 From: field

Here's an unmangled copy of the patch. I think this works, but the \" part acts a little weird during testing. (E.g. if I run -editidx I can fix an index page, but I can't seem to break it again if I change the code back) -Jeff # diff -u /var/tmp/mhutil.pl /usr/share/mhonarc/mhutil.pl --- /var/t

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #5, bug #20142 (project mhonarc): --- /var/tmp/mhutil.pl 2007-10-09 20:30:36.0 -0700 +++ /usr/share/mhonarc/mhutil.pl2007-10-09 21:32:05.0 -0700 @@ -176,7 +176,8 @@ foreach $tok (@tokens) { next if $skip; if ($tok =~ /^"/) { # Quo

[bug #18113] inconsistant thread slices w/ poor man's windowing

Follow-up Comment #3, bug #18113 (project mhonarc): I ran on a handful of list messages (10 of them) and added them to a mhonarc archive one at a time, with MAXSIZE set to 3. This version preserved the thread slices, while 2.6.16 pretty much clobbered the thread slices. Looks good to me. __

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #4, bug #20142 (project mhonarc): I've placed a sample of raw messages at the following location. It is encrypted to the mhonarc signing key and is representative of production traffic. Maybe the size is a little bit of overkill for this particular problem, but the dataset might

[bug #13853] creation of archive with attachments writes over symlinks

Follow-up Comment #7, bug #13853 (project mhonarc): >1 Add a FOLLOWSYMLINKS resource that tells mhonarc to leave >symlinks alone. This would have to be explicitly enabled. Maybe go with whatever sounds easiest, and that's probably this one. I keep my mhonarc patched to essentially do this, and

[bug #17579] message ID's are censored along with addresses

Follow-up Comment #2, bug #17579 (project mhonarc): I see this request as pretty obscure and less important than other bug reports. ___ Reply to this item at: ___

[bug #18112] produces broken links

Follow-up Comment #2, bug #18112 (project mhonarc): The work around for this is - for us - is to detect and kill off this type of broken at serving time. So not so critical from my perspective. ___ Reply to this item at:

[bug #17563] mhonarc trashes malformed HTML

Follow-up Comment #1, bug #17563 (project mhonarc): We don't bother with HTML mail any more when there's any choice in the matter, so not so important to us. ___ Reply to this item at: _

[bug #19142] Right-to-left paragraphs not aligned to the right

Follow-up Comment #1, bug #19142 (project mhonarc): I'm interested in right-to-left as well, but how would the parser detect that the paragraph is RTL? Is the only way to do this by analyzing the character set or are there other indicators? And if it is by character set, can web browsers be set

[bug #18113] inconsistant thread slices w/ poor man's windowing

Follow-up Comment #1, bug #18113 (project mhonarc): I wonder how hard this is. ___ Reply to this item at: ___ Message sent via/by Savannah http://

[bug #20142] strip backslash in rfc822 From: field

Follow-up Comment #2, bug #20142 (project mhonarc): This is super useful, and really comes into play for us on $FROMNAME$. Everything else can essentially stay the same. In particular, $SUBJECT$ will quite often have unescaped backslashes, for example, a message talking about Windows software m

Re: [bug #20252] [gnu.org #336933] RFC2047 header encoding bug

I don't have a mhonarc install to test it. Is it possible to install and process a single message right-away without setting up MTA integration, etc? Yes. As a side note #1 I have the names of 564 gnu.org and nongnu.org mailing lists that have been hand checked and determined to be completely

Re: [bug #20252] [gnu.org #336933] RFC2047 header encoding bug

[ -savannah because I am lazy ] Ok, well we do have proof that mhonarc is capable of doing the right thing on the exact same message. I use the TEXTENCODE resource to send everything to UTF-8, which is probably the recommended mhonarc way of doing things these days anyway. http://www.mhonarc.org

[bug #20252] [gnu.org #336933] RFC2047 header encoding bug

Follow-up Comment #1, bug #20252 (project mhonarc): Not a mhonarc bug. Almost certainly, mhonarc is converting the name to UTF-8, but Apache is sending the web page out with an ISO-8859-1 header. Here's an example of mhonarc doing just fine with a message from the same person. http://www.mail-

[bug #20252] [gnu.org #336933] RFC2047 header encoding bug

Follow-up Comment #2, bug #20252 (project mhonarc): And here's the exact message. Note the combination of Chinese, English, and umlauts; unicode is the only answer. http://www.mail-archive.com/[EMAIL PROTECTED]/msg02923.html ___ Reply

[bug #20142] strip backslash in rfc822 From: field

URL: Summary: strip backslash in rfc822 From: field Project: MHonArc Submitted by: jab Submitted on: Sunday 06/10/2007 at 19:19 Category: Resource Variables Severit

Re: profiling results

> Another > possible win is reviewing resource files and see if > there are some unnecessary variables that can be > trimmed out. I'll go ahead and do the latter since it > is super easy. One possibility is to have meta-resource files to abstract strings (like you do for L10N strings). You proce

[bug #18113] inconsistant thread slices w/ poor man's windowing

URL: Summary: inconsistant thread slices w/ poor man's windowing Project: MHonArc Submitted by: jab Submitted on: Thursday 10/26/2006 at 05:28 Category: Threading S

[bug #18112] produces broken links

URL: Summary: produces broken links Project: MHonArc Submitted by: jab Submitted on: Thursday 10/26/2006 at 05:22 Category: None Severity: 3 - Normal

[bug #17579] message ID's are censored along with addresses

URL: Summary: message ID's are censored along with addresses Project: MHonArc Submitted by: jab Submitted on: Thursday 08/31/2006 at 06:10 Category: None Severity:

[bug #17563] mhonarc trashes malformed HTML

URL: Summary: mhonarc trashes malformed HTML Project: MHonArc Submitted by: jab Submitted on: Tuesday 08/29/2006 at 02:56 Category: Mail Parsing Severity: 3 - Norma

[bug #15415] mhonarc eats part of a message

Follow-up Comment #8, bug #15415 (project mhonarc): I just attached a file that has the same symptoms; "show" from nmh can't see the message nor can mhonarc. It's also multipart/alternative. However, I'm not seeing a telltale double text/html section. This is a YahooGroups message. __

[bug #15415] mhonarc eats part of a message

Additional Item Attachment, bug #15415 (project mhonarc): File name: 9138.gzSize:10 KB very similar symptoms ___ Reply to this item at:

[bug #15415] mhonarc eats part of a message

Follow-up Comment #6, bug #15415 (project mhonarc): > Ok, we've pretty much confirmed that the blame goes to the list > server software (Lyris). Do you know the version number of the > software? Do you have contact info for the person administering > the list server? > > I'm going to contact the

[bug #15415] mhonarc eats part of a message

Additional Item Attachment, bug #15415 (project mhonarc): File name: after Size:6 KB message AFTER going through list server ___ Reply

[bug #15415] mhonarc eats part of a message

Follow-up Comment #4, bug #15415 (project mhonarc): Ok, it's interesting. The program "show" from nmh does not like the message after it had gone through Lyris. But comparing the two messages ('before' and 'after') line by line, I'm not sure exactly what went wrong. Earl, can you point out the p

[bug #15415] mhonarc eats part of a message

Follow-up Comment #3, bug #15415 (project mhonarc): I had the poster send a message to the list, and also put me personally on the BCC: line. The goal was to find out where the problem occurred. Mhonarc is quite happy with the message until after it goes through the list server. Current hypothesi

[bug #15415] mhonarc eats part of a message

Additional Item Attachment, bug #15415 (project mhonarc): File name: after Size:6 KB message AFTER going through list server ___ Reply

[bug #15415] mhonarc eats part of a message

Additional Item Attachment, bug #15415 (project mhonarc): File name: before Size:8 KB message NOT going through list server ___ Reply to

invalid UTF-8

When mhonarc is producing UTF-8 using the TEXTENCODE resource, does it ever produce invalid UTF-8? I ask because I'm taking some mhonarc output, stripping the HTML, then feeding the results to a Perl based text analysis program. Which occasionally complains bitterly, for example: Malformed UTF-8

[bug #15415] mhonarc eats part of a message

Follow-up Comment #1, bug #15415 (project mhonarc): I suspect this is due to the unusual triple MIME section (text/html/text) MIME sections and may be actually be a mhonarc buglet. Probably the MUA is providing the first two sections, and the list server is tacking on the third.

[bug #15415] mhonarc eats part of a message

URL: Summary: mhonarc eats part of a message Project: MHonArc Submitted by: jab Submitted on: Tue 01/10/06 at 05:28 Category: Mail Parsing S

[bug #13853] creation of archive with attachments writes over symlinks

Follow-up Comment #6, bug #13853 (project mhonarc): I'm not sure checks #2 and #3 actually buy anything more than what is already available with unix file permission, and may be more trouble than benefit. If the filesystem says it's ok to write, that that's probably good enough. So just #1 is fi

[bug #15074] Wrong $SUBJECTNA:U$ substitution for subject with mime encoding

URL: Summary: Wrong $SUBJECTNA:U$ substitution for subject with mime encoding Project: MHonArc Submitted by: jab Submitted on: Sat 11/26/05 at 21:41 Categor

[bug #14747] major (10X) memory savings possible in some situations

URL: Summary: major (10X) memory savings possible in some situations Project: MHonArc Submitted by: jab Submitted on: Sat 10/08/05 at 04:11 Category: None

Re: [approved] Fwd: Bug#332653: mhonarc: Huge memory usage (>>1Gb on 30Mb mail box) (patch)

Is it possible to get the submitter to post a bug report to savannah? Or at a minimum, add report to savannah linking to the debian report. I'll make sure one or the other happens. Note, I think mail-archive.com should be immune to this problem since it is now utilizing TEXTENCODE, so mail-

[approved] Fwd: Bug#332653: mhonarc: Huge memory usage (>>1Gb on 30Mb mail box) (patch)

I got an interesting bug report via Debian just now. Not quite sure what to make of it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332653 -Jeff - To sign-off this list, send email to [EMAIL PROTECTED] with the message text

[bug #13853] creation of archive with attachments writes over symlinks

Follow-up Comment #3, bug #13853 (project mhonarc): >The symlink check is done to prevent local symlink attacks. >Somebody else recently reported a problem with mhonarc's behavior: . Please post a follow-up to the report providing

Re: Would like to create a new MHonArc release

Ok, I just went through the draft performance guide as a checklist. Pretty neat, I didn't know about MODTIME. Here are some possible improvements. (1) Run a spellcheck. There's some typos, for example practive -> practice inorder -> in order negligable -> neglibile (2) Use MIMEINC

MHonArc 2.6.12 for Debian

MHonArc 2.6.12 is now packaged for Debian will hit Debian Unstable (sid) within 24 hours. --Jeff - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV

's in format=flowed

>Seemingly, this shouldn't be necessary - that is the whole point of >format=flowed, to allow SR's. Is there a switch to tell mhonarc to >only wrap text/plain fixed, but to *not* wrap flowed (instead >just dropping SR's and converting HR's to 's). Users complained about MHonarc 2.6.10 doing exa

CharEnt.pm report

>Were you able to examine some converted UTF-8 messages or is >your evaluation based upon what you see in your logs? Mostly logs and lack of user complaints. A quick spot checks also looks positive, for example the following message was produced by GMail with a UTF-8 encoding. This particular li

CharEnt.pm report

The new CharEnt.pm appears to be working well after 2+ days in production. No problems noticed so far, and the error logs are quite clean. Cheers, Jeff - To sign-off this list, send email to [EMAIL PROTECTED] with the message te

UTF-8 filtering in MHonArc

Ok, I put the revised CharEnt.pm in production. Should have reportable results Tuesday morning (the daily log resets at ~7am). Cheers, Jeff - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCR

UTF-8 filtering in MHonArc

>I am downloading 5.8.6 to upgrade my 5.8.0 install to see if behavior >changes, along with playing with mhonarc code to see if I can get >some consistency and a better understanding of Perl's behavior. Please let me know how that goes. FYI, Debian Sarge ships with perl 5.8.4, but it isn't too ha

lots of UTF-8 warnings

I'm seeing a lot of UTF-8 warnings woth 2.6.11. Is this expected? perl v5.8.4, mhonarc 2.6.11 Malformed UTF-8 character (1 byte, need 3, after start byte 0xef) in unpack at /usr/share/mhonarc/MHonArc/CharEnt.pm line 156. - To

UTF-8 warnings in 2,6,11

I'm seeing quite a few UTF-8 warnings on 2.6.11. Is this expected? Cheers, Jeff Malformed UTF-8 character (unexpected continuation byte 0xac, with no preceding start byte) in unpack at /usr/share/mhonarc/MHonArc/CharEnt.pm line 156. Malformed UTF-8 character (1 byte, need 3, after start byte

[approved] [bug #12512] Consecutive spaces not displayed in some cases

Follow-up Comment #1, bug #12512 (project mhonarc): Trying again to link to http://www.mail-archive.com/gossip%40jab.org/msg01032.html>thread ___ Reply to this item at:

[approved] [bug #12512] Consecutive spaces not displayed in some cases

URL: Summary: Consecutive spaces not displayed in some cases Project: MHonArc Submitted by: jab Submitted on: Thu 03/31/2005 at 06:18 Category: MIME Filter

[approved] Fwd: Bug#297007: @INC problems with mhonarc

: jeff@jab.org Cc: [EMAIL PROTECTED] Hi Jeff, On Mon, Mar 21, 2005 at 11:47:28PM -0500, Jeff Breidenbach wrote: > I'm sorry, is this a change you made to mharc or mhonarc? Opps, sorry I left that out - the change was in /usr/share/mhonarc/mhamain.pl Hope that is clear enough. Thanks

[approved] [bugs #12314] linebreak not utf-8 aware

Follow-up Comment #1, bugs #12314 (project mhonarc): > This one is interesting. We have the told Mhonarc to break lines > once they hit 80 characters. This was for English language users > who don't know how to hit the return key. Our CSS layout isn't > happy when the message body gets too wide.

[approved] [bugs #12314] linebreak not utf-8 aware

URL: Summary: linebreak not utf-8 aware Project: MHonArc Submitted by: jab Submitted on: Mon 03/14/2005 at 07:49 Category: Character Sets Se

[approved] [bugs #11762] rel=nofollow attribute support in message body hyperlinks

URL: Summary: rel=nofollow attribute support in message body hyperlinks Project: MHonArc Submitted by: jab Submitted on: Fri 01/28/2005 at 07:39 Category:

[approved] [bugs #11763] reverse indexes not suitable for search engines

URL: Summary: reverse indexes not suitable for search engines Project: MHonArc Submitted by: jab Submitted on: Fri 01/28/2005 at 07:46 Category: None

[approved] [bugs #11761] spammode causes broken mailto: links in message body

URL: Summary: spammode causes broken mailto: links in message body Project: MHonArc Submitted by: jab Submitted on: Fri 01/28/2005 at 07:35 Category: Mail P

[approved] [bugs #11759] email address exposed in subject line

URL: Summary: email address exposed in subject line Project: MHonArc Submitted by: jab Submitted on: Fri 01/28/2005 at 07:29 Category: Resource Variables

[approved] [bugs #11760] spammode false positives on some HTML mail

URL: Summary: spammode false positives on some HTML mail Project: MHonArc Submitted by: jab Submitted on: Fri 01/28/2005 at 07:33 Category: Mail Parsing

Re: Need help with Segmentation fault

>The format=flowed code appears to cause perl to go into an infinite loop >with the regex patterns used to process format=flowed data. I was >able to crash v5.6.1 and v5.8.0 of perl under linux. It looks like Debian is tracking this same problem as a Perl bug. Even if future MHonArcs no longer t

Re: July 31st shown as July 30th twice

Possible mhonarc bug reported by Debian users. Details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155305&repeatmerged=yes -Jeff On Sun, 2002-10-27 at 07:23, Josip Rodin wrote: > reassign 155305 mhonarc > thanks > > Hi, > > The page in question is > >http://lists.debian.org/debian-l1