Mailman 3 May 1999 - Mailman-Developers

stalled connection: archive locks?
by Ricardo Kustner 21 May '99

21 May '99

Hi, well i've traced my problem back to the fact that the lock files in the archive directory are not being removed. they appear as: 1999-May-subject.lock.<host-name>.<#####> where <#####> is a number... does anybody have the same problems? i think this might be what causes the process-overload on our server, when an impatient moderator doesnt wait for the stalled page to completely finnish and approve several posts at once, all of them waiting for lock files to be released...? Ricardo.

1 0

Error in Mailman Version: 1.0rc1
by Richard Ellerbrock 21 May '99

21 May '99

I continuously get the following error in my error log. Unfortunately I do not know what leads to the error. admin: [----- Mailman Version: 1.0rc1 -----] admin: [----- Traceback ------] admin: Traceback (innermost last): admin: File "/home/mailman/scripts/driver", line 112, in run_main admin: main() admin: File "/home/mailman/Mailman/Cgi/listinfo.py", line 40, in main admin: FormatListinfoOverview() admin: File "/home/mailman/Mailman/Cgi/listinfo.py", line 66, in FormatListinf oOverview admin: if port and http_host[-len(port)-1:] == ':'+port: admin: AttributeError: __getslice__ -- Richard Ellerbrock richarde(a)eskom.co.za

1 0

found a bug? "ValueError: bad marshal data"
by Ricardo - Miss Janet. Fanclub 21 May '99

21 May '99

Hi, like i mentioned earlier, when i approve a post with admindb, the webbrowser stalls for several seconds before closing the connection... well i just found out that it generates an error in my apache logs (See below) is this a bug? or does this mean one of the databases is corrupted? if so, how can i fix it? i'm using mailman rc1 on Linux 2.0.36, i upgraded python to 1.5.2 yesterday, but the same problems were before that. ps: don't you all agree mailman needs more publicity? i think it's one of the best mailinglist solutions... but one of the powers behind GNU like software is when many people help to develop it; and i'm sure there are a lot of developers out there who can and want to help... i gotta start learning python soon! :) did rc1 get posted on freshmeat and stuff? Thanks... Ricardo. [Fri May 21 06:34:29 1999] [error] [client 212.206.29.123] File does not exist: /usr/local/www/miss-janet.com/www/images/mailman.gif Traceback (innermost last): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 209, in ArchiveMail h.processUnixMailbox(f, HyperArch.Article) File "/usr/local/mailman/Mailman/Archiver/pipermail.py", line 381, in processUnixMailbox self.add_article(a) # Add the article File "/usr/local/mailman/Mailman/Archiver/HyperArch.py", line 846, in add_article parentID=self.database.getOldestArticle(self.archive, File "/usr/local/mailman/Mailman/Archiver/HyperDatabase.py", line 285, in getOldestArticle self.__openIndices(archive) File "/usr/local/mailman/Mailman/Archiver/HyperDatabase.py", line 228, in __openIndices t=DumbBTree(os.path.join(arcdir, archive+'-'+i)) File "/usr/local/mailman/Mailman/Archiver/HyperDatabase.py", line 56, in __init__ self.dict = marshal.load(open(path)) ValueError: bad marshal data Ricardo. -- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Fax/phone: +31-(0)20-7764493 Email: fanclub(a)miss-janet.com Or check out our website: http://miss-janet.com

1 0

getheader-setheader
by Bencsath Boldizsar 21 May '99

21 May '99

i have submitted this as bug, but i get some expertise in mailman python routines ;)) so : The problem, if i use special characters in the subject, some of the words appear two times in the subject ... To: <boldi(a)budapest.hu>, <teszt(a)carnation.hu> Subject: =?iso-8859-2?B?Rnc6IGZ1cmEg6WdpIG1hc2luYSBu9nZlbGkgbWFnYXNz4WfhdCA=?= =?iso-8859-2?B?bmFwaG9zc3phdCBr7Xbpbg==?= Date: Fri, 21 May 1999 01:04:51 +0200 This is the original header. Note, that the Subject: header has TWO lines.. Getheader is parsing well. But setheader is going to do: else: for i in range(len(self.headers)): if (string.lower(self.headers[i][:len(name)+1]) == string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) (1.0rc1-message.py [ line 173 of 307 (56%), character 5740 of 9761 (58%) ]) Because of this, setheader () takes out ONE line, not BOTH. I am not using python, so dont know even the basic commands, would anyone help me to correct this bug and sending me before the next release comes out? ;) I think it should be no problem with my instructions boldi -answer in private(i'm not a developer ) boldi(a)budapest.hu

1 0

Re: [Mailman-Developers] features suggestion: languages
by Harald Meland 20 May '99

20 May '99

[Bognar, Attila] > Hi all, > > I'm quite new to this list. > I faced a "problem": I run a maillists for Hungarian people and the > problem is that some of them don't speak english very much. So I > have/should change the English text to Hungarian. > > So what I suggest: > when creating a new list, there could be a question, which asks what > language the list should be. > The datas of languages could be taken for example from > ~mailman/templates/hungarian/ > > What do you think? The issue has been brought up a number of times before -- and at the moment, there's not much more to say about it than "Support for internationalization is one of the things high on our TODO list for post-1.0". -- Harald

1 0

features suggestion: languages
by Bognar, Attila 20 May '99

20 May '99

Hi all, I'm quite new to this list. I faced a "problem": I run a maillists for Hungarian people and the problem is that some of them don't speak english very much. So I have/should change the English text to Hungarian. So what I suggest: when creating a new list, there could be a question, which asks what language the list should be. The datas of languages could be taken for example from ~mailman/templates/hungarian/ What do you think? Attila

1 0

Re: [Mailman-Developers] Bug in archive dating in 1.0RC1
by Harald Meland 18 May '99

18 May '99

[Jeff Hahn] > background: > > list has the "Set date in archive to when the mail is claimed to have been > sent, or to the time we resend it?" set to WHEN RESENT > > email message with the following headers creates an archive record in > September of 2022! NOTE: look at the second Received: line. I'm unable to reproduce this. If anyone else see similar effects, or know how to make this reproducible (or maybe even can produce a patch to fix this :), please speak up. It should be noted, though, that the "clobber_date" configuration option only seems to be supported by the __archive_to_mbox() method, and not by the ArchiveMail() method that Post() invokes. There are comments in there indicating that __archive_to_mbox is a previous but now renamed ArchiveMail() -- but I don't know whether it's intended for the current ArchiveMail() method not to care about clobber_date. -- Harald

1 0

Bug in archive dating in 1.0RC1
by Jeff Hahn 16 May '99

16 May '99

background: list has the "Set date in archive to when the mail is claimed to have been sent, or to the time we resend it?" set to WHEN RESENT email message with the following headers creates an archive record in September of 2022! NOTE: look at the second Received: line. names and IP addresses have been "sanitized" to protect STUPID IDIOT who is running a mail server with the date set at Fri, 2 Sep 2022 Mailman still should have ignored the date and used the date when MAILMAN resent it (or am I wrong about that option's intent?) I apologize for not jumping in to fix this, but I'm really pressed for the next couple of days and I don't know how tight a schedule we are on for the release candidates... -Jeff

1 0

RE: [Mailman-Developers] In-Reply-To vs. References
by Aahz 15 May '99

15 May '99

Harald Meland wrote: > > ... and before anyone gets religious on me here, I'll rush to explain > that I _do_ see the harm of inserting "faulty" References: headers -- > any In-Reply-To: candidate should at the very least be in the form of > a valid message ID. > > I think there was a slightly similar discussion on the (ding) Gnus > mailing list a while back -- it was spurred by the fact that Gnus' > threading sometimes broke down, as some mailers put several > message-id-look-a-like-tags (e.g. mail addresses in angle brackets) in > their In-Reply-To: header. Threading is already broken on the newsreader side if References: doesn't exist. I'd say that as long as it has the correct form, pass it on. (I'm also making the possible faulty assumption that the Gnus problem manifested in the context of reading a mailing list rather than a newsgroup.)

1 0

Re: [Mailman-Developers] In-Reply-To vs. References
by Harald Meland 15 May '99

15 May '99

[Harald Meland] > (Not having read c.l.p,) I don't understand how such a proposition > could generate much of a discussion :) Having read the discussion in c.l.p, I now understand :) > If an email contains an In-Reply-To: header, I'd guess it is due to it > being a reply. If this email is gated to news, the fact that it is a > reply, and preferably what message it is a reply to, should be > indicated somehow. > > If such an indication can only be given by having the news-gate muck > around with the headers of the message, _and_ such mucking won't > destroy any of the _original_ headers of the message, I don't really > see the harm. ... and before anyone gets religious on me here, I'll rush to explain that I _do_ see the harm of inserting "faulty" References: headers -- any In-Reply-To: candidate should at the very least be in the form of a valid message ID. I think there was a slightly similar discussion on the (ding) Gnus mailing list a while back -- it was spurred by the fact that Gnus' threading sometimes broke down, as some mailers put several message-id-look-a-like-tags (e.g. mail addresses in angle brackets) in their In-Reply-To: header. Thus, Mailman should be very conservative when moving MessageID-candidates from In-Reply-To: to References: -- it might even be a good idea to query the newsserver whether it has the candidate replied-to article (even though that probably won't work with all newsserver configurations). If the appropriate level of conservatism can be reached without making the involved code *too* complex, I still believe this particular case of header mucking could be a Good Thing. -- Harald

1 0