Bug#4082: No documentation for fvwm modules
Package: fvwm Version: 1.24r-24 Documentation for the fvwm modules appears to be missing from this package. [Insert obligatory renewal of the fvwm-package-relying-on-fvwm2-package debate here.] :-) I only noticed this because I tried to look up information on GoodStuff. This module appears to be available only in the fvwm package, and consequently there is no corresponding documentation in the fvwm2 package. (There appears to be an otherwise full complement of Fvwm* man pages in the fvwm2 package.) -- Larry Gilbert [EMAIL PROTECTED] Seattle, WA, USA I speak only for myself and not for my employer
Bug#4476: Remove "error-message activism" :-)
Package: xpdf Version: 0.5-0 More of a misfeature than a bug. There is an error message that pops up when xpdf tries to open an encrypted PDF file. It complains that Adobe has not released decryption specs to developers, and implores the user to e-mail Adobe to complain. The latest information at the xpdf home page states that Adobe has finally released the decryption specs. It also says that a new version of xpdf is in the works, but its release is uncertain. It might be wise to change the error message until a new version of xpdf is released by the author. Just a polite gesture more than anything else. :-) This is the error message in question: Error (0): PDF file is encrypted and cannot be displayed Error (0): * Please send email to [EMAIL PROTECTED] and ask Error (0): * them to prove that PDF is truly an open standard by Error (0): * releasing the decryption specs to developers. Also, Error (0): * please send email to the person responsible for this Error (0): * file ([EMAIL PROTECTED] might be a good place) and ask Error (0): * them to stop using encrypted PDF files. -- Larry Gilbert, technical support (Bess & Rainier.Net) [EMAIL PROTECTED]
Re: RBL report..
Rather than contribute to the flame war, I would like to ask a question. Apologies if this is a total rookie question. Why is murphy.debian.org not adding a "Received:" header to show where messages are originating? This information is useful when trying to track down actual spammers. Is this being deliberately omitted or does qmail just normally not include this info? -- Larry Gilbert Seattle, WA, USA <[EMAIL PROTECTED]>
Re: RFP: bidwatcher
Hi Bdale, Since I'm the one maintaining the SourceForge version, maybe you and I should talk. :-) -- Larry Gilbert Seattle, WA, USA <[EMAIL PROTECTED]> On Sun, 26 Mar 2000, Bdale Garbee wrote: > The original author has abdicated, and a fork has occurred. I'm currently > using the version from Wayne Schlitt <[EMAIL PROTECTED]>, which can be > found at http://www.midwestcs.com/bidwatcher/. There is another version > at SourceForge, and the good news is the two folks didn't know they were > working in parallel, and have now agreed to work towards a merge using the > SourceForge site in the future. The code is GPL'ed, and does not include > the extra wording needed for GPL'ed code linking with QT. That needs to be > resolved before an upload. > > Any takers?
Re: RBL report..
On Wed, 29 Mar 2000, Branden Robinson wrote: > Some MTA's -- and I don't know which ones -- apparently choke if there is > more than n bytes' worth of Received: headers. > > So, as I understand it, these are stripped out by murphy to help make sure > the list mails get to all the recipients. Maybe murphy could somehow be made to insert the information into a different header, then? It would be nice to be able to report spam problems to appropriate parties, but an easily-forged e-mail address isn't enough evidence to go on. Does anyone know which mail servers were choking on too many "Received:" lines, and whether that is still a problem? -- Larry Gilbert Seattle, WA, USA <[EMAIL PROTECTED]>
