Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > * New upstream release \1 > > * fixed "BTS summary line of #1" Closes: #1 > > * fixed "BTS summary line of #2" Closes: #2 > > * fixed "BTS summary line of #3" Closes: #3 > > > > in changelogs would probably go a lot further to correcting this very minor > > issue than reopening dozens of bug reports that belong closed, annoying > > users > > with BTS garbage, and repeating the same thread on debian-devel over and > > over. > > Yes, that sounds pretty intesresting; an addition to debian-changelog-mode > would be interesting. > > It should be possible to get bugs.debian.org/ and parse the resulting > HTML for the title and the original submitter, and placing it. > > Some addition to debian-changelog-close-bug, possibly optional, > that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) > to parse the bugreport ? Here is what the output looks like: ecasound2.2 (2.3.0-1) UNRELEASED; urgency=low * New upstream release * Run autoconf-automae-libtool in build. * jackd requires /proc/cpuinfo information not available on zaurus From: Junichi Uekawa (closes: #207435) -- Junichi Uekawa <[EMAIL PROTECTED]> Sat, 30 Aug 2003 13:16:07 +0900 and here is the patch against debian-bug.el and debian-changelog-mode.el diff -ur orig/debian-bug.el mods/debian-bug.el --- orig/debian-bug.el 2003-08-30 12:44:24.0 +0900 +++ mods/debian-bug.el 2003-08-30 13:22:59.0 +0900 @@ -1440,7 +1440,7 @@ (forward-sexp 1) (beginning-of-line)) -(defun debian-bug-wget-mbox (&optional bug-number) +(defun debian-bug-wget-mbox-or-html (download-mbox-p &optional bug-number) "Wget the mbox file for bug BUG-NUMBER and return the filename created." (if (not debian-bug-download-directory) (error "Please set ` debian-bug-download-directory'")) @@ -1456,11 +1456,17 @@ (concat "debian-bug-" (if debian-bug-package-name (concat debian-bug-package-name "-")) - bug-number) + bug-number +(if download-mbox-p +"" + ".html")) debian-bug-download-directory)) (status) (url (concat "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug="; - bug-number "&mbox=yes"))) + bug-number + (if download-mbox-p + "&mbox=yes" +"" (if (and (file-exists-p filename) (not (y-or-n-p "Bug file already exists. Download again? "))) filename @@ -1472,6 +1478,14 @@ filename (error "`wget' failed")) +(defun debian-bug-wget-mbox (&optional bug-number) + "Wget the mbox file for bug BUG-NUMBER and return the filename created." + (debian-bug-wget-mbox-or-html t bug-number)) + +(defun debian-bug-wget-html (&optional bug-number) + "Wget the html file for bug BUG-NUMBER and return the filename created." + (debian-bug-wget-mbox-or-html nil bug-number)) + (defun debian-bug-get-bug-as-file (&optional bug-number) "Browse the BTS for BUG-NUMBER via `browse-url'." (interactive (list (completing-read "Bug number to fetch: " diff -ur orig/debian-changelog-mode.el mods/debian-changelog-mode.el --- orig/debian-changelog-mode.el 2003-08-30 12:44:18.0 +0900 +++ mods/debian-changelog-mode.el 2003-08-30 13:15:35.0 +0900 @@ -645,7 +645,22 @@ (if (not (string-match "^[0-9]+$" bug-number)) (error "The bug number should consists of only digits.")) (debian-changelog-add-entry) - (save-excursion (insert " (closes: #" bug-number ")")) + (save-excursion +(insert + (with-current-buffer +(find-file-noselect (debian-bug-wget-html bug-number)) + (beginning-of-buffer) + (concat + (progn + + (re-search-forward "\\([^-]*- #[^-]*- \\)\\([^<]*\\)") + (match-string 2)) + "\nFrom: " + (progn + (re-search-forward "From: \\([^&]*\\)") + (match-string 1)) + ))) +(insert " (closes: #" bug-number ")")) (message "Enter a brief description of what was done here.")) ;;
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 06:00:51PM -0400, Glenn Maynard wrote: > A script to convert eg. > > * New upstream release .* (Closes: #1, #2, #3) > > to > > * New upstream release \1 > * fixed "BTS summary line of #1" Closes: #1 > * fixed "BTS summary line of #2" Closes: #2 > * fixed "BTS summary line of #3" Closes: #3 > > in changelogs would probably go a lot further to correcting this very minor > issue than reopening dozens of bug reports that belong closed, annoying users > with BTS garbage, and repeating the same thread on debian-devel over and over. One big problem with this approach is that the same maintainers who are too lazy to write proper entries for bug-closers in their changelog entries are going to be too lazy to ensure that a bug report has a meaningful summary in the first place. -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe pgpaB7wR3YuAx.pgp Description: PGP signature
Re: configure web proxy via DHCP server
On Sat, Aug 30, 2003 at 12:01:42PM +1000, Brian May wrote: > Is this possible? > > It would be really "cool"(tm) if I didn't have to reconfigure every > program on my laptop to use a different proxy server every time I plug > it into a different network. > > Just venting my irritation for the day... [snip] Run a local proxy that forwards connections to the (external) proxy of your choice, and point all applications at it? T -- Do not reason with the unreasonable; you lose by definition.
configure web proxy via DHCP server
Is this possible? It would be really "cool"(tm) if I didn't have to reconfigure every program on my laptop to use a different proxy server every time I plug it into a different network. Just venting my irritation for the day... -- Brian May <[EMAIL PROTECTED]>
Re: That movie
Your email to Crown International has been sent. You should receive a response within 1 business day. If you need a faster response, feel free to contact us Toll Free at 1-800-715-4227 during regular business hours. Thank You, James P. Cox President, Crown International
debian archive disk space requirements.
Hi, I've noticed the growth in the debian archive with some concern over the last few weeks/months. We're now hitting the limit of the partition that debian is on and it will be quite difficult technically for us to deal with this in the short term. We have some new storage which is being comissioned but it won't be in place for about a month and the debian archive has already filled up a 100G partition we've dedicated to it here (that doesn't include the debian-cd or debian-non-US or other debian related archives.. just the main debian one). I'm stuck between a rock and a hard place here as we have a large dependency tree before we can move equipment over and get access to the new disk.. Is there any way to reduce the size of the archive over the next 4-6 weeks ? regards, -jason
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
I'm cc'ing PSG, maybe he'll be interested. > * New upstream release .* (Closes: #1, #2, #3) > > to > > * New upstream release \1 > * fixed "BTS summary line of #1" Closes: #1 > * fixed "BTS summary line of #2" Closes: #2 > * fixed "BTS summary line of #3" Closes: #3 > > in changelogs would probably go a lot further to correcting this very minor > issue than reopening dozens of bug reports that belong closed, annoying users > with BTS garbage, and repeating the same thread on debian-devel over and over. Yes, that sounds pretty intesresting; an addition to debian-changelog-mode would be interesting. It should be possible to get bugs.debian.org/ and parse the resulting HTML for the title and the original submitter, and placing it. Some addition to debian-changelog-close-bug, possibly optional, that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) to parse the bugreport ? regards, junichi
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: > the point that you keep on missing is that TMDA and similar programs send > "confirmation" emails to innocent third-parties who did *NOT* send an email. > > TMDA and all C-R systems are broken-by-design, just as many stupid end-user > "autoresponders" and AV-scanners that send notifications back to the forged > sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. The other option which many people seem to want is to discard the E-Mail without giving either party any indication of what happened. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. Do you simply discard such E-Mails (which gives no indication that something went wrong), or do you try to contact the sender to indicate that something went wrong? The problem is that I see no easy way to fix this problem to the large scale required on the Internet while keeping store-and-forward "feature" of SMTP. One approach for instance would be to modify the SMTP standard, and say if a host accepts the E-Mail then it is guaranteed to get it to the destination (ie. it signal OK until the message has been delivered), but that would break store-and-forward capabilities of secondary mail servers. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 01:42:53AM +1000, Russell Coker wrote: > PS Before someone raises the issue of license of viruses. I believe that > anyone who distributes a virus does so with the desire that it be installed > on as many systems as possible and that the implied license permits you to > have a copy of it for whatever purposes you desire. People who wish to limit > the use of their software in any way should make it refrain from installing > itself on hundreds of thousands of machines without the consent of the > owners. :-# ... but you don't always get the source code, this is required by the DFSG ;-). -- Brian May <[EMAIL PROTECTED]>
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 04:34:58PM -0500, Adam Heath wrote: > It's not about summarizing how the bug was fixed. It's about summarizing the > bug *itself* in the changelog. > > The description of the bug is already available(as the title of the bug > report). At the very least this should be placed in the debian changelog. How is this abusive? The maintainer is putting useful information in the changelog (the release a given bug was fixed), and closing the bug in the process. Not including a description of the bug seems no worse than not listing closed bugs in the changelog at all, and closing them all separately later on; I'm sure many maintainers without time to revisit lots of bugs after each upstream release do this. A script to convert eg. * New upstream release .* (Closes: #1, #2, #3) to * New upstream release \1 * fixed "BTS summary line of #1" Closes: #1 * fixed "BTS summary line of #2" Closes: #2 * fixed "BTS summary line of #3" Closes: #3 in changelogs would probably go a lot further to correcting this very minor issue than reopening dozens of bug reports that belong closed, annoying users with BTS garbage, and repeating the same thread on debian-devel over and over. -- Glenn Maynard
MISC
Dear Candidate, Thank you for getting in touch with Prometric Auto Response System. We are in receipt of your e-mail. This e-mail contains the following I. KEY WORDS TO PUT IN THE SUBJECT FIELD OF YOUR E-MAIL TO US. In order to get a reply from us, you are required to put ONE of the relevant key words in the subject field of your e-mail to us. ** I. KEY WORDS TO BE PUT IN THE SUBJECT FIELD OF YOUR E-MAIL In order to get a reply from us, you are required to put ONE of the relevant key words in the subject field of your e-mail to us. FAILING THIS, WE WOULD BE UNABLE TO RESPOND TO YOU ANY FURTHER . KEY WORDS A. CONFIRMATION: All queries related to your exam date. Also queries on test date allocated to you. B. RESCHEDULE: Request FOR RESCHEDULING test date, queries regarding rescheduled test date allocated. Also for requests for CANCELLATION of test date, and queries regarding the same.. C. PAYMENT : All queries related to Credit card decline notice Credit Card not charged ASR Payments D. NAME :Queries related to candidate's name as it appears in the test registration E. TEST CENTER ADDRESS: F. SCORE REPORTS: In case you would like to get the answers to the most frequently asked questions by candidates, please write the name of the test ( GRE or GMAT or TOEFL) in your e-mail. * Candidate Services (India) Prometric , a part of the Thomson Corporation Senior Plaza 160 A Gautam Nagar Yusuf Sarai New Delhi 110049
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 09:31:29AM -0400, Joe Drew wrote: > Fine. Then don't close them with the Debian changelog at all; instead, > use [EMAIL PROTECTED], with an explanation that it is fixed in > such-and-such a version. The changelog bug closing facility is only a > convenience. I'm confused. We have three cases: 1. Close bug #12345 directly (12345-done), noting the version that fixed it. 2. Note in the changelog that bug #12345 is fixed; the bug receives a notification of the version that fixed it. 3. Note in the changelog that bug #12345, "ls --crash crashes", is fixed; the bug receives a notification of the version that fixed it. #3 is obviously ideal, if the maintainer has time; no debate there. However, you're saying that #1 is preferable to #2. Why? It seems to have no disadvantage to #1, with the added advantages that I can check which version fixed bug #12345 without hitting the network (since it's documented in the changelog), and saves developer time. What am I missing? -- Glenn Maynard
Re: DebToo: Debian, Gentoo-style
On Thu, Aug 28, 2003 at 09:16:04PM +1000, Brian May wrote: > Of course there are downsides either way, but there is no dispute > that the size of the Debian archive is huge, and mirrors are struggling > to keep up as a result. Is this so? I havent seen reports in this area for a while. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
unsubscribe
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2003 2:08 AM Subject: debian-devel-digest Digest V2003 #1147
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 29 Aug 2003, Glenn Maynard wrote: > If I report "segmentation fault in ls", I--as a user of ls, not a > developer--couldn't care less about why it was segfaulting or how the > bug was fixed; I only care that it's been fixed. If a developer wants > to spend their limited time researching how the bug was fixed and > summarizing it in a changelog, great, but it's certainly not something I'd > expect everyone to do. It's not about summarizing how the bug was fixed. It's about summarizing the bug *itself* in the changelog. The description of the bug is already available(as the title of the bug report). At the very least this should be placed in the debian changelog.
Re: dpkg -- overwrite empty directories?
On Fri, 29 Aug 2003, Ryan Underwood wrote: > > Hello, > > I have a package that Replaces: another package. The former package > stored files in a particular directory (/usr/lib/foo); when the package > is removed, it leaves that directory behind, empty. The new package has > a symlink at that location, instead of a directory. dpkg, however, does > not replace the directory with the symlink. Hence, I have to > specifically check for this situation in maintainer scripts, and remove > the empty directory if it exists. > > Am I way off base here, or would it be robust behavior for dpkg to > replace empty directories with symlinks, files, whatever, if the empty > directory is not claimed by a currently installed package? It could be > argued that the package that left the empty directory behind is broken, > so I'm looking for circumstances in which my proposed behavior would > present a problem. Nope. Check the dpkg bug list and policy. This is not a feature that will change. Hint: consider when an admin moves a dir to a new location, and places a symlink at the old location.
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 12:12, Joshua Kwan wrote: > On Fri, Aug 29, 2003 at 11:37:57AM +1000, Russell Coker wrote: > > If someone is to Joe-Job me then I'd rather that mailing lists bounce the > > messages, if it gets bad I could filter out all mailing list messages > > temporarily. > > Hmm, how about giving tmda its own special header so we can auto-filter > out messages from people who use C-R systems? Sounds like a good idea! Or even better don't make it a TMDA header make it a generic C-R header, I don't want a header check rule for every C-R system out there. > It's a bit extreme but I'm sick of deleting such messages, especially in > light of the Blaster worm. Not extreme at all. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: > the point that you keep on missing is that TMDA and similar programs send > "confirmation" emails to innocent third-parties who did *NOT* send an email. Really? > TMDA and all C-R systems are broken-by-design, just as many stupid end-user > "autoresponders" and AV-scanners that send notifications back to the forged > sender address are broken-by-design. Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
glibc 2.3.2 and testing
Hi, I'd like to know, why all recently updated and new packages in testing have a dependancy on glibc >= 2.3.2? Wouldn't it be enough if they depend just on glibc? BTW: Why are all those packages going into testing if they are uninstallable? Regards, Mike Dornberger PS: Please Cc me, I'm not subscribed to dd.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > "The bug has been fixed" is everything I would need to know. I don't > > really care if it was a typo, a new library, a rebuild or some magic > > incantation with black dribbling candles, the bug has been fixed. On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: > This approach surely don't raise the level of Debian. > Maybe *you* do not care of the details about the bug you reported. But > a Debian developer is entitled, normally, to provide information > according to what *users* can expect. On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: > I do. If you want to see every change which was made to the source, read the upstream Changelog. If you want to see Debian packaging changes, read the Debian Changelog. It's simple really. :) Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 08:48:13PM +0200, Mathieu Roy wrote: > There's at least one other solution: what if, when a bug tagged > "upstream" was closed, the mail sent would include the upstream > ChangeLog (hopefully named ChangeLog in the top directory of the > package)? > Can someone familiar with the BTS code tell whether this change is > trivial or not? It's not trivial in the slightest, sorry. The BTS doesn't remotely have this information available to it, and it's not even easy to arrange for it to be available. -- Colin Watson [EMAIL PROTECTED]
Re: GDM in sid does not read /etc/environment anymore
I've actually sent him an email but got no answer. I've posted in debian-devel few days ago and nobody complained that GDM could source /etc/environment in the init script. That's an one-line patch (already tagged as patch in bts for more than a year)... I think that if the maintainer doesn't take that, a NMU will be neecessary. Em Sex, 2003-08-29 às 14:33, Javier Fernández-Sanguino Peña escreveu: > On Fri, Aug 29, 2003 at 05:01:54PM +0200, Petter Reinholdtsen wrote: > > [Fabio Rafael da Rosa] > > > I upgraded sid two days ago, and starting X via gdm does not set the > > > environment variable I've set in /etc/environment. Anyone has the > > > same problem ..? > > > > It is probably a PAM configuration problem. You need the following > > line in the /etc/pam.d/ file used by gdm: > > Not really, I believe it's bug #133578 and #147091 and #192143. Feel > free to pester the maintainer, let's hope this gets fixed > (i.e. before sarge gets "frozen") > > Regards > > Javi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:05:21AM -0500, Adam Heath wrote: > A proper entry is as follows: > > * New upstream release. > * no longer does foo when bar happens. Closes: #12345 > * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 > > Please, everyone remember, a changelog documents *changes*. It's not a tool > to close bugs automatically. It documents which revision closed bug #12345. That's useful information for a changelog. It's certainly not worse than saying only "new upstream revision" and closing the bugs manually. > The BTS sends these close messages to the submitter when the bug is closed. > However, the email above has no reason as to why the bug was closed. It's not > sufficient to just say a new upstream version was uploaded, which just happens > to fix the bug. As a submitter, would you feel satisified that you had just > gotten such a mail? Absolutely! I reported a bug, and the mail says that the bug I reported has been fixed. That's all I need to know. If I report "segmentation fault in ls", I--as a user of ls, not a developer--couldn't care less about why it was segfaulting or how the bug was fixed; I only care that it's been fixed. If a developer wants to spend their limited time researching how the bug was fixed and summarizing it in a changelog, great, but it's certainly not something I'd expect everyone to do. (As a user, I'd certainly be rather annoyed at receiving duplicate close reports because someone reopened the bug for frivelous reasons, however. I get enough junk mail already.) -- Glenn Maynard
Bug#207791: ITP: ITP: libdata-formvalidator-perl -- Library for easily validating user input, mainly for HTML
Package: wnpp Version: unavailable; reported 2003-08-29 Severity: wishlist * Package name: ITP: libdata-formvalidator-perl Version : 3.12 Upstream Author : Mark Stosberg <[EMAIL PROTECTED]> * URL : http://www.cpan.org/modules/by-module/Data/ * License : GPL + Artistic Description : Library for easily validating user input, mainly for HTML Provides a clean interface to present the user with template-generated forms, which will be later automatically validated, in a very easy to use and understand fashion. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux jerx 2.4.21-gwolf #1 Fri Jun 27 13:04:09 CDT 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: glibc 2.3.2 and testing
On Fri, Aug 29, 2003 at 05:46:54PM +0200, Mike Dornberger wrote: > I'd like to know, why all recently updated and new packages in testing have > a dependancy on glibc >= 2.3.2? Wouldn't it be enough if they depend just > on glibc? Binaries built against glibc 2.3.2 really do depend on glibc 2.3.2 [1]. They may not if built against glibc 2.3.1, but that's a different matter. [1] Well, they may depend on glibc 2.3.2, at least. We don't have the infrastructure yet to pick apart symbol versioning in order to say for sure, but in the absence of that it's better to be conservative. On my system 'objdump -p /bin/cat' shows that cat requires glibc 2.3, so glibc alone is certainly not adequate. > BTW: Why are all those packages going into testing if they are > uninstallable? I'm afraid you're mistaken. I've just checked, and there are no packages currently in testing that depend on glibc 2.3.2. You must actually be using unstable. Cheers, -- Colin Watson [EMAIL PROTECTED]
dpkg -- overwrite empty directories?
Hello, I have a package that Replaces: another package. The former package stored files in a particular directory (/usr/lib/foo); when the package is removed, it leaves that directory behind, empty. The new package has a symlink at that location, instead of a directory. dpkg, however, does not replace the directory with the symlink. Hence, I have to specifically check for this situation in maintainer scripts, and remove the empty directory if it exists. Am I way off base here, or would it be robust behavior for dpkg to replace empty directories with symlinks, files, whatever, if the empty directory is not claimed by a currently installed package? It could be argued that the package that left the empty directory behind is broken, so I'm looking for circumstances in which my proposed behavior would present a problem. Perhaps a warning would also be a good idea, so that the replacement package doesn't silently fail when a directory was attempted to be overwritten. -- Ryan Underwood, , icq=10317253
点击“网赚导航”实现网上赚钱梦想
µã»÷ http://hengingv.533.net ½Ì¸øÄúÈçºÎÀûÓÃÍøÂç׬Ǯ
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> a tapoté : > On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: > > > We've gone through this many times already. Upstream changes should > > > not be documented in the Debian changelog, even if they fix bugs in > > > the Debian BTS. > > > > Because users that submitted bugs using the Debian BTS do not deserve > > the right to get a mail meaningful about the bug they reported? > > "The bug has been fixed" is everything I would need to know. I don't > really care if it was a typo, a new library, a rebuild or some magic > incantation with black dribbling candles, the bug has been fixed. This approach surely don't raise the level of Debian. Maybe *you* do not care of the details about the bug you reported. But a Debian developer is entitled, normally, to provide information according to what *users* can expect. We are not here speaking about what some people do not care about but what some debian users do care about and how they can be easily satisfied. The fact that frequently we have to talk about that proves at least one thing: some users do care about details of the bugs and expect to get them in the changelog they receive by mails. If as debian developer you do care about what some *users* wants, the safest solution is to provide this information. It should takes you about 3 minutes to document these bugfixes. It is too much? Regards, -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 12:12:58PM +1000, Russell Coker wrote: > On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: > > When the next address-spoofing virus hits, if I need to update my filters > > again, I'll make a better effort to do it ASAP instead of letting it go for > > several days. > > Why not make your tmda package depend on amavis-new and clamav-freshclam? If > they are installed and correctly configured then virus filters should get > updated as fast as is possible. Does Amavis automatically configure itself for whatever MTA is installed and start scanning mail immediately? If not, then I don't see how a Depends: would help. I would consider adding a Suggests: or Recommends:. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
袁林
北京子撰图文设计中心 本公司是北京专业的平面设计中心，有平面设计专家、专业设计师亲自动手为您的事业锦上添花！ 服务项目包括： 企业形象设计 企业广告创意、设计制作 平面广告创意、设计制作 企业产品包装设计、制版、印刷 企业产品宣传册设计、制版、印刷 精美印刷品设计、制版、印刷 报纸广告、杂志广告设计、制版 精美彩色杂志设计、制版、印刷 海报设计、制版、印刷 图书封面设计、制版、印刷 户外、室内广告喷绘设计制作 联系人：袁林 TEL：13311210700 010-85762212 E-mail : [EMAIL PROTECTED]
Re: libraries being removed from the archive
On Tue, 05 Aug 2003 07:32:57 +0200, Matthias Urlichs wrote: > Hi, Peter Mathiasson wrote: > >> "[...] distcc sends the complete preprocessed source code across the >> network for each job." > > Hmm, OK, but that would just speedup the actual compilation. Granted, > that's the largest chunk, but cpp/asm/ld could do with a speed-up too. As a point of information, distcc runs the assembler remotely too (in this case, on the x86). cpp's CPU usage is usually negligible, and while ld can be slow it is often a small fraction of the total time. Building a cross suite with the excellent Debian toolchain-source package is easy, and I regularly use that to have several x86 machines help with ia64 builds. For many packages the biggest problem is actually ./configure, since it is slow and not parallelizable. -- Martin
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: > On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: > > #2, Misplaced burden, is the reason for the 'grave' severity. > > People have a right to ask that unkown people that e-mail them confirm the > e-mail. the point that you keep on missing is that TMDA and similar programs send "confirmation" emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user "autoresponders" and AV-scanners that send notifications back to the forged sender address are broken-by-design. such software is too brain-damaged to use. there is more than enough spam, viruses and other garbage clogging SMTP servers around the world without making things worse by using programs which falsely claim to be part of the solution. junk like this does not solve the problem, it is not part of the solution - it just amplifies the original problem: every virus or spam with forged headers results in even more "confirmation" and/or "notification" messages being sent in response. in short, it is automated spamware that contributes to denial of service attacks. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
reassign 207300 humanity thanks On pe, 2003-08-29 at 10:36, Adam McKenna wrote: > Well, since we're pointing fingers, it's really SMTP that's broken by > design, and all anti-spam programs (including C-R systems) are merely > stopgap measures that try to make up for SMTP's shortcomings. The fact that SMTP now needs authentication and what not points at the real problem: there are greedy and evil people willing to exploit anything for their personal benefit. In the interest of fixing things once and for all, that flaw in humanity needs to be fixed. It is not enough to kill all greedy and evil people, since new ones will be born. I propose killing all humans and letting the planet be inherited by us Martians. On a more serious note, it would be interesting to have a thought experiment of how an e-mail system could be designed from scratch (no compatibility with SMTP needed). Debian-devel is not the forum for it, though. I develop and maintain one mailing list manager, and it will send confirmation requests for subscriptions, unsubscriptions, and messages that will wait for moderation. I'll make it so that it will avoid sending them if the message that triggered them looks too much like spam. At least that much good results from this thread. :) -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 09:20:49PM +0100, Karsten M. Self wrote: > on Thu, Aug 28, 2003 at 01:03:37AM -0700, Adam McKenna ([EMAIL PROTECTED]) > wrote: > > > Also, I don't have any hard data to support this, but it's obvious to > > me that the volume of mail generated by virus scanners in response to > > Sobig.f eclipses the volume of TMDA challenges by at least a factor of > > 10. So far, I haven't received *one* TMDA challenge that was due to > > Sobig, but I've received *hundreds* of messages from virus scanners > > all over the net. > > > > So, I guess we should add virus scanners to the list of verboten > > software. > > My own inbox supports this statement. 140 responses to Sobig.F mails, > of which 43 are virus or other content-based autoresponders, and 97 > being delivery failure messages or other autoresponders (e.g.: ISP help > desk). How many were challenges from mailing list software? Yes, another class of software that automatically issues challenges (specifically, to new subscriptions and to non-list members if the list is closed). So I guess you should also file bugs against majordomo, mailman, ezmlm-src, and any other mailing list managers that do this. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: > When the next address-spoofing virus hits, if I need to update my filters > again, I'll make a better effort to do it ASAP instead of letting it go for > several days. Why not make your tmda package depend on amavis-new and clamav-freshclam? If they are installed and correctly configured then virus filters should get updated as fast as is possible. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:41:54PM +0100, Mark Brown wrote: > That doesn't help all that much - it's also important see why the bug > has been closed. Because it is fixed... > whatever it was I was trying to do when I generated the error rather > than by fixing the error handling. it wont help you, if it says "print a helpful error message". If you realy care that much, look up the patch. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna ([EMAIL PROTECTED]) wrote: > On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: > > #2, Misplaced burden, is the reason for the 'grave' severity. > > People have a right to ask that unkown people that e-mail them confirm > the e-mail. I'm sorry you don't agree with this, but your opinion is > hardly justification for a grave bug. People also have the responsibility to accept, personally, the responsibility for using, developing, and distributing systems which impose this burden on others. If you wish to undertake the distribution of TMDA yourself, with your own resources, you are free to do so. You may not demand the right to transfer these consequences on the Debian Project and SPI over the objections (if present) of the project at large. Determining the will of the Debian project is a purpose of this discussion. > > - TMDA should carry a warning to the user about possible consequences > > of activating the C-R mechanism, including sending spam, risking > > blacklisting or registration in spam-reduction services such as > > SpamCop, and a likelihood that some, and perhaps a majority of > > challenges will not be responded to. The warning should require the > > user to assume full responsibility for doing so. > > Sorry, but no. I will not do this. The user presumably knows what he is > installing. "The User" demonstrably does not, in all, and possibly in most, circumstances. In my own cites of TMDA mailing list experiences, users have apparently spammed thousands of arbitrary addresses with C-R challenges, and have found their own systems listed by spam-prevention systems, with neither the user, nor the architect of TMDA realizing the significance and externalized costs of TMDA. Moreover, inclusion of debconf warning messages is *NOT* a responsibility of upstream, but of the Debian package maintainer. > > - Configuration templates for C-R challenges _must_ incorporate virus > > and spam filtering, _prior_ to issuing a C-R challenge. Preferably, > > tests against obvious header spoofing, if possible, should be > > performed. Debian tmda packages _must_ depend on corresponding spam > > and virus filters, if this functionality isn't built into TMDA. > > > > - Additional strong validation mechanisms, including RFC 2015 PGP > > signed mail and S/MIME signatures, _must_ be used to validate > > sender, including use of web of trust to identify a reasonable > > probability of trusted user status. > > > > - If possible, TMDA should be moved to SMTP-time filtering, so that > > mail rejection occurs at SMTP time. As SMTP doesn't offer a > > protocol for challenge-response, this introduces interesting > > challenges for TMDA's developers. > > > > - TMDA's performance _must_ be independently validated and the target > > maximum of 2% challenges to spoofed addresses be confirmed. > > > > > > > > I'm not going to pretend that these are easy fixes. I'm not a user of > > this package. I _am_ negatively impacted by it, however, and if it > > continues to display similarly poor consideration of security, abuse, > > and adverse side effects, I fear for Debian, SPI, and the generosity of > > our sponsors. I do feel the remedies are necessary and advised. They > > should be communicated upstream, naturally. > > I suggest you take these suggestions to the TMDA worker's mailing list at > tmda.net, and file wishlist bugs against TMDA for each desired feature. For what reason can these suggestions not be accomplished (excepting SMTP-time filtering and independent validation) through providing a template which applies the proper processing order to a C-R challenge issuing change, and C-R issuance be disabled unless working AV, spamfilters, and signature validation SW are installed? Seems to me upstream needn't be involved at all. Peace. -- Karsten M. Self http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Sick of mal-formed websites? A stylesheet to override poor design: http://twiki.iwethey.org/Main/UserContentCSS pgpmcc4tXb539.pgp Description: PGP signature
source code on sh4
debian-devel，Hi！ Where can I find the source code on sh4 for Debian linux Best Regard! Cong Ming [EMAIL PROTECTED] 2003-08-29
$B!ZL$>5Bz9-9p![K\F|Cf$K(B100$BK|Kx(B
$B"#5^$0$"$J$?$N6/$$L#J}!*%"%$%(!<%+!<%I$N%b%P%$%k%-%c%C%7%s%0(B $B"#$*?=$79~$_$+$i?69~$_$^$G:GB.(B20$BJ,!#5^$J=PHq$G$*:$$j$NJ}92$F$kA0$K$^$:Ev\:Y$*$h$S%a!<%k$G$N$*?=$79~$_$O%"%$%(!<%+!<%I(BHP$B!!(Bhttp://www.i-a-ai.com/aiei/index.html $B"#$*EEOC$G$N$*?=$79~$_$O%U%j!<[EMAIL (BPROTECTED]"%k(B0120$B!](B61$B!](B8484$B!J7HBS!&(BPHS$B2D!K(B $B"#El5~ETCN;v!J(B1$B!KBh(B22962$B9f(B
Anti-Virus software has detected a virus in a document you authored.
Please contact your system administrator. The infected file attachment in the scanned document was deleted. Virus Information: The attachment your_details.pif contained the virus [EMAIL PROTECTED] and was deleted.
Bug#207709: ITP: module-assistant -- helper script to automate kernel module building
Package: wnpp Version: unavailable; reported 2003-08-28 Severity: wishlist * Package name: module-assistant Version : 0.1 (currently beeing written) Upstream Author : myself, nativ package * URL : http://modass.alioth.debian.org (when it has been approved) * License : LGPL Description : helper script to automate kernel module building Here the current usage info and rationale, package description will be done when the most functionality is there: # # Script to assist users with building of the kernel modules # First purpose: automate as much as possible for Joe User # Second purpose: have a database about the source of module packages # (and all steps needed to get it) # Third purpose: provide general debian/rules include snippets # USAGE: # autobuild name|all|dir-list [ alternatives headers dir, list ] # locate the right kernel source or headers directory and build the # given modules with them. Primary choice for most people. # # auto-install (ai) # like autobuild but also tries to install the created packages # # list-available (la), list-installed (li), list-everything (le) # get name|all|dir-list [ alternative headers dir, list ] # download (gets implies download) # update (update the lists, version numbers) # build name|all|dir-list [ alternatives headers dir, list ] # Lists are collon-separated Directory tree of the module-assistant How does the whole thing work? Every package that should be controlled with modass provides a maintainer script (see below) that accepts the following commands: update updates the intenal data when needed, eg. version number. Scripts can do whatever they want, any may use the /var/lib/modass/cache directory as playground for caching the data. version outputs the current version of the package; syntax == dpkg-style lastpkg outputs the filename (full path) of the last built package. Empty if the build was not successful. download installs the source package or fetches the source with apt-get/apt-src/whatever unpack unpacks the downloaded package source in $MODULE_LOC purge removes the working source directory and cached data purge-all like purge plus removes the binary packages built from the source Ressource directory (planned location: /usr/share/modass) modass |-- include (files to be sourced by package maintaining scripts and makefile includes) |-- overrides (package maintscripts taking precedence over the default ones) `-- packages(some default scripts, provided by the modass package itself) Package maintainence scripts are either shipped with module-assistant or installed by other binary package that have something to do with the modules. For example, cloop-utils installs one into modass/overrides/. Of course no module source package does support all this know. For this reason, I plan to import them all in a big SVN repository on alioth, having the Debian branch and Modified branch and working on them. All good things from their rules files will be extracted and merged into common rules which will become part of module-assistang (similar to the story of dbs and dpatch packages). Eduard. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.20-wolk4.6s #1 Mi Aug 6 11:42:42 CEST 2003 i686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
Re: NEED HELP: Making woody LSB compliant
Martin Schulze wrote: > Updated alien > > The alien changes have been in testing and unstable for a similar > amount of time. > > Unfortunately I can't find the source for the above packages. ...? Context error. > I also remember some talk about start-stop-daemon having to be > altered. What about this one? > Task: Review and discuss the changes against original packages The relevant differences in alien are those made in revisions 8.15, 8.16, 8.17, and 8.20. All of these have to do with handling of user, groups, and permissions in files in the converted packages. None of thsse are strictly necessary for LSB compliance, they're all just bug fixes for corner cases that some lsb packages could possibly trigger. One lsb package that happens to trigger some of them is the lsb test suite rpm. -- see shy jo pgpL3OacHtPfO.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 04:31:59PM +, benfoley wrote:
> On Friday 29 August 2003 09:28, Steve Lamb wrote:
> > On Fri, 29 Aug 2003 00:36:57 -0700
> > Adam McKenna <[EMAIL PROTECTED]> wrote:
> > > Well, since we're pointing fingers, it's really SMTP that's broken by
> > > design, and all anti-spam programs (including C-R systems) are merely
> > > stopgap measures that try to make up for SMTP's shortcomings.
> >
> > Oddly enough Spamassassin doesn't exasperate the problem. TDMA does.
>
> exacerbate is probably what you meant here.
Actually, I think exasperate is perfectly valid as well.
From WordNet (r) 1.7 [wn]:
exasperate
v 1: exasperate or irritate [syn: {exacerbate}, {aggravate}]
2: make furious [syn: {outrage}, {infuriate}, {incense}]
3: make worse; "This drug aggravates the pain" [syn: {worsen},
{aggravate}, {exacerbate}] [ant: {better}]
- Keegan
pgpkdhOOQymzr.pgp
Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> a tapoté : > > > "The bug has been fixed" is everything I would need to know. I don't > > > really care if it was a typo, a new library, a rebuild or some magic > > > incantation with black dribbling candles, the bug has been fixed. > > On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: > > This approach surely don't raise the level of Debian. > > Maybe *you* do not care of the details about the bug you reported. But > > a Debian developer is entitled, normally, to provide information > > according to what *users* can expect. > > On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: > > I do. > > If you want to see every change which was made to the source, read the > upstream Changelog. If you want to see Debian packaging changes, read > the Debian Changelog. It's simple really. :) The debian changelog have the wonderful advantage to be sent by mail when a bug is closed. This person do not want to see "every change which was made to the source" neither do her want to see "Debian packaging changes" but want to see the change about the submitted bug. To get that information in the mail sent, the only solution would be to have it included in the debian changelog. There's at least one other solution: what if, when a bug tagged "upstream" was closed, the mail sent would include the upstream ChangeLog (hopefully named ChangeLog in the top directory of the package)? Can someone familiar with the BTS code tell whether this change is trivial or not? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 00:36:57 -0700 Adam McKenna <[EMAIL PROTECTED]> wrote: > Well, since we're pointing fingers, it's really SMTP that's broken by > design, and all anti-spam programs (including C-R systems) are merely > stopgap measures that try to make up for SMTP's shortcomings. Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp81Uf26k2Ll.pgp Description: PGP signature
Re: Details
hello, Can't reply to your mail at the moment, I will reply as soon when possible. If you didn't send a message, please control your pc for virusses. greetings christophe
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 02:46:48AM +0200, Tore Anderson wrote: > Earlier, you've stated that your time is precious. Well, so is mine. > How dare you assume that the time I spent reviewing *your* callenge mail > and deciding it was junk is less precious than the time you (could have) > spent reviewing the mail that spurred the challenge in the first place? > > I admit my first email was written in hot blood, but if TMDA actually > endorses this selfish behaviour, I still feel it is something that do > not belong in Debian. On the other hand, if the junk mail in my > inbox was a result of a misconfiguration on your part, then I'm > sorry for yelling so loud. Errare humanum est. I've already stated that I've modified my incoming mail filters so that these viruses will no longer hit TMDA. I feel bad that others were affected due to my misconfiguration, but it was user error (or laziness in this case) that caused this, not a fundamental problem with the software. When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MAIL FOLDER "INBOX - IMOBILIARE" CLOSED DUE TO ACCESS ERROR
I do receive "a lot" of messages and use pine's filtering features to sort them out to different folders. The same thing happened with folder "IMOBILIARE". I have sorted there some messages after i've readed them. After i renamed the folder from "Imobiliare" to "IMOBILIARE" no one folder's open enymore.Each time i try to acces Folders (trash, sent etc) it rites me: ERROR: Could not complete request. Query: EXAMINE "INBOX IMOBILIARE" Reasone Given: Invalid Mailbox What should i do now? Please give me an advice. --- WWW.COM - Where The Web Begins! http://www.www.com/
Re: GDM in sid does not read /etc/environment anymore
On Fri, Aug 29, 2003 at 05:01:54PM +0200, Petter Reinholdtsen wrote: > [Fabio Rafael da Rosa] > > I upgraded sid two days ago, and starting X via gdm does not set the > > environment variable I've set in /etc/environment. Anyone has the > > same problem ..? > > It is probably a PAM configuration problem. You need the following > line in the /etc/pam.d/ file used by gdm: Not really, I believe it's bug #133578 and #147091 and #192143. Feel free to pester the maintainer, let's hope this gets fixed (i.e. before sarge gets "frozen") Regards Javi pgp5JZLSYL0pG.pgp Description: PGP signature
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): > > [Short version: see the patch below.] > (after a few days w/o answers from Snort's maintainer) > Sander, any comments wrt to this patch? Please at least say wether you are > going to forward this to Snort maintainers or use it in order to not break > snort packages on upgrades. Thanks for that patch. I'm forwarding it to snort-devel. I hope they'll implement it. I wasn't planning on using it to patch debian released snorts, really. Sander. -- | Visitors always give pleasure: if not on arrival, then on the departure. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D pgpsxazqDS3d6.pgp Description: PGP signature
Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
At Thu, 28 Aug 2003 10:24:15 +0200, Andreas Barth wrote: > Really? The latest glibc in sarge is from 2003-03-22, and there are > currently 1103 packages waiting for glibc. I may need to explain the status glibc: 2003-03-22 glibc is 2.3.1-17. The next version of glibc is 2.3.2-2, which was uploaded in 2003-08-06. So, this block has kept from 2003-08-06. About 3 weeks. The reason I duploaded information at: http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00047.html The current version is 2.3.2-4. We're working for fixing bugs, some bugs were resolved. Regards, -- gotom
Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
* GOTO Masanori ([EMAIL PROTECTED]) [030829 11:05]: > I may need to explain the status glibc: > [...] > > The current version is 2.3.2-4. We're working for fixing bugs, > some bugs were resolved. Sorry, I didn't want to step on your feet. I know that glibc is a nasty beast, and you're really good at handling it. glibc was just an example that a base package might be broken for some time when there are major updates; one just can't prevent that (otherwise we won't need unstable, testing and stable and a freeze phase). Only - that this hinders binary compatibility between the different releases. To the glibc-team: Keep up your good work. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 09:47, Adam McKenna wrote: > On Fri, Aug 29, 2003 at 09:20:53AM +1000, Russell Coker wrote: > > The comparison to mailing list software makes no sense. > > Maybe not in the context of viruses, but for the "Joe Job" problem it does. If someone is to Joe-Job me then I'd rather that mailing lists bounce the messages, if it gets bad I could filter out all mailing list messages temporarily. If someone Joe-Jobbing me results in messages from me getting delivered to mailing lists then that would be worse than having the lists bounce them IMHO (before you ask, I've been Joe-Jobbed before). When someone else gets Joe-Jobbed I'd rather deal with the spam using DNSBL and spam-assasin to protect myself. For spam that gets through that I would rather just report it to SpamCop myself than add to the problems of the poor sod who's being Joe-Jobbed. > Viruses can and should be filtered out before they reach the C-R system. True, that's one of the things that should be in large warnings on any C-R system in Debian. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: MEI Whitelist Autoresponse
On Fri, Aug 29, 2003 at 11:37:57AM +1000, Russell Coker wrote: > If someone is to Joe-Job me then I'd rather that mailing lists bounce the > messages, if it gets bad I could filter out all mailing list messages > temporarily. Hmm, how about giving tmda its own special header so we can auto-filter out messages from people who use C-R systems? It's a bit extreme but I'm sick of deleting such messages, especially in light of the Blaster worm. -- Joshua Kwan pgp5YUHB41QSw.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu wrote: This is bullshit. We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Fine. Then don't close them with the Debian changelog at all; instead, use [EMAIL PROTECTED], with an explanation that it is fixed in such-and-such a version. The changelog bug closing facility is only a convenience.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
* Adam McKenna > #0, #1, #2 and #11 are basically opinion and rhetoric. Well. Let's take a look at what Karsten had to say about point #2, "Misplaced burden": [...] «C-R may place the burden on third parties either inadvertently (via spoofed sender spam or virus mail), or deliberately (see Joe-job below).» [...] You dismiss this as "basically opinion and rhetoric". Yet, I see a unsolicited junk mail from you, yes - *you* Adam, in my mailbox. I'd be very interested in hearing how that could've been a result of 'opinion and rhetoric', so please, let me know. Earlier, you've stated that your time is precious. Well, so is mine. How dare you assume that the time I spent reviewing *your* callenge mail and deciding it was junk is less precious than the time you (could have) spent reviewing the mail that spurred the challenge in the first place? I admit my first email was written in hot blood, but if TMDA actually endorses this selfish behaviour, I still feel it is something that do not belong in Debian. On the other hand, if the junk mail in my inbox was a result of a misconfiguration on your part, then I'm sorry for yelling so loud. Errare humanum est. -- Tore Anderson
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 07:55, Adam McKenna wrote: > > My own inbox supports this statement. 140 responses to Sobig.F mails, > > of which 43 are virus or other content-based autoresponders, and 97 > > being delivery failure messages or other autoresponders (e.g.: ISP help > > desk). > > How many were challenges from mailing list software? Yes, another class of > software that automatically issues challenges (specifically, to new > subscriptions and to non-list members if the list is closed). So I guess > you should also file bugs against majordomo, mailman, ezmlm-src, and any > other mailing list managers that do this. The comparison to mailing list software makes no sense. I am prepared to put up with majordomo or mailman responses to virus messages because it's for the greater good. Having a single unwanted message go to me is much better than having that message being sent out to each of the 10,000 people on a big mailing list! For challenge-response systems it's totally different. I don't want to receive a single message because a lazy asshole wants to push all his problems on other people. People who take the attitude of "Sobig wasn't a problem, my machine just sent out 4000 challenge messages to random victims" can only be described as lazy assholes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu <[EMAIL PROTECTED]> a tapoté : > Adam Heath <[EMAIL PROTECTED]> wrote: > > > > On Wed, 27 Aug 2003, Ean R. Schuessler wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> > >> Format: 1.7 > >> Date: Wed, 27 Aug 2003 17:18:37 -0500 > >> Source: kaffe > >> Binary: kaffe > >> Architecture: source i386 > >> Version: 1:1.1.1-1 > >> Distribution: unstable > >> Urgency: low > >> Maintainer: Ean R. Schuessler <[EMAIL PROTECTED]> > >> Changed-By: Ean R. Schuessler <[EMAIL PROTECTED]> > >> Description: > >> kaffe - A JVM to run Java bytecode > >> Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021 > >> 170059 193263 196254 196867 197617 200434 202779 > >> Changes: > >> kaffe (1:1.1.1-1) unstable; urgency=low > >> . > >>* New upstream release closes many bugs. (Closes: #51230, #61264, > >> #75800, #77869, #116802, #141597, #158743, #170021, #170059, > >> #193263, #196254, #197617, #202779, #81389, #200434, #196867) > >>* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936) > > > > This is not a proper changelog entry. > > > > A proper entry is as follows: > > > > * New upstream release. > > * no longer does foo when bar happens. Closes: #12345 > > * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 > > > > Please, everyone remember, a changelog documents *changes*. It's not a tool > > to close bugs automatically. > > This is bullshit. > > We've gone through this many times already. Upstream changes should > not be documented in the Debian changelog, even if they fix bugs in > the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Olivia Erickson is out of the office.
I will be out of the office starting 08/28/2003 and will not return until 09/02/2003. I will respond to your message when I return.
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 09:20:49PM +0100, Karsten M. Self wrote: > The virus responses are irresponsible, and have been for almost two years > as the number of sender-spoofing emails has grown. BTW, amavisd-new has # Treat envelope sender address as unreliable and don't send sender # notification / bounces if name(s) of detected virus(es) match the list. # Note that virus names are supplied by external virus scanner(s) and are # not standardized, so virus names may need to be adjusted. # See README.lookups for syntax. # $viruses_that_fake_sender_re = new_RE( qr'nimda|hybris|klez|bugbear|yaha|braid|sobig|fizzer|palyh|peido|holar'i ); -- 2. That which causes joy or happiness.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> wrote: > On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: >> > We've gone through this many times already. Upstream changes should >> > not be documented in the Debian changelog, even if they fix bugs in >> > the Debian BTS. >> >> Because users that submitted bugs using the Debian BTS do not deserve >> the right to get a mail meaningful about the bug they reported? > > "The bug has been fixed" is everything I would need to know. I don't > really care if it was a typo, a new library, a rebuild or some magic > incantation with black dribbling candles, I do. --Nikolaus
Re: MEI Whitelist Autoresponse
on Fri, Aug 29, 2003 at 09:20:53AM +1000, Russell Coker ([EMAIL PROTECTED]) wrote: > On Fri, 29 Aug 2003 07:55, Adam McKenna wrote: > > > My own inbox supports this statement. 140 responses to Sobig.F mails, > > > of which 43 are virus or other content-based autoresponders, and 97 > > > being delivery failure messages or other autoresponders (e.g.: ISP help > > > desk). > > > > How many were challenges from mailing list software? Yes, another class of > > software that automatically issues challenges (specifically, to new > > subscriptions and to non-list members if the list is closed). So I guess > > you should also file bugs against majordomo, mailman, ezmlm-src, and any > > other mailing list managers that do this. > > The comparison to mailing list software makes no sense. > > I am prepared to put up with majordomo or mailman responses to virus > messages because it's for the greater good. Having a single unwanted > message go to me is much better than having that message being sent > out to each of the 10,000 people on a big mailing list! > > For challenge-response systems it's totally different. I don't want > to receive a single message because a lazy asshole wants to push all > his problems on other people. > > People who take the attitude of "Sobig wasn't a problem, my machine > just sent out 4000 challenge messages to random victims" can only be > described as lazy assholes. Karsten M. Self repeats the preceding allegations of the Complaint as if set forth here in full[1]. Mailing lists are a rather small subset of all mail recipients, though they may be overrepresented in address lists harvested by spammers. In addition, however, list software _should_ filter virus and spam mail prior to sending a "your message to foo list awaits moderation". Peace. Notes: 1. Someone has been sending too much time reading legal docs. -- Karsten M. Self http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? SCO vs IBM Linux lawsuit info: http://sco.iwethey.org pgp79zv54k5Uj.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 16:31:59 + benfoley <[EMAIL PROTECTED]> wrote: > On Friday 29 August 2003 09:28, Steve Lamb wrote: > > Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. > exacerbate is probably what you meant here. Quite so. 1:30am emails before the requisite round of CS to wake-up are prone to errors, no? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpMC75FKYQ9o.pgp Description: PGP signature
Re: GDM in sid does not read /etc/environment anymore
[Fabio Rafael da Rosa] > I upgraded sid two days ago, and starting X via gdm does not set the > environment variable I've set in /etc/environment. Anyone has the > same problem ..? It is probably a PAM configuration problem. You need the following line in the /etc/pam.d/ file used by gdm: auth required pam_env.so For kdm in Woody, the file is called 'kde'. I'm not sure which file gdm is using.
GDM in sid does not read /etc/environment anymore
I upgraded sid two days ago, and starting X via gdm does not set the environment variable I've set in /etc/environment. Anyone has the same problem ..? -- Fabio Rafael da Rosa - f 2 r <[EMAIL PROTECTED]> Debian- http://debian.org Debian-BR - http://debian-br.org Debian-SP - http://sp.debian-br.org "Let the programmers be many and the managers few then all will be productive."
Re: MEI Whitelist Autoresponse
On Fri, Aug 29, 2003 at 01:51:58PM +1000, Russell Coker wrote: > > It's a bit extreme but I'm sick of deleting such messages, especially in > > light of the Blaster worm. > > Not extreme at all. I imagine there are some legitimate people I might receive emails from, reply to them and never know it didn't get sent. That's my only problem with this approach, although it would be possible to tell procmail to stick C-R responses into some special folder... And once you have reached that point it's nearly as bad as not filtering them at all. Granted, lack of a reply is earned punishment for using a C-R system IMNSHO. -- Joshua Kwan pgpH4aEhJ3Y8L.pgp Description: PGP signature
Re: source code on sh4
On Friday 29 August 2003 10:29, wrote: > debian-devel，Hi！ > >Where can I find the source code on sh4 for Debian linux http://www.m17n.org/linux-sh/debian/ and go from there. greetings -- vbi -- Sterility is inherited. If your parents never had kids, odds are you wont either. -- William R. James in news.admin.net-abuse.email pgp04io0V5TgU.pgp Description: signature
Re: looking for nco maintainer Brain Mays
On Wed, Aug 27, 2003 at 08:25:30PM -0400, Brian Mays wrote: > > Thus, the situation is as follows. If someone can point me to an new > upstream source that is fairly similar to the source in the current > Debian package, then I can incorporate these changes into Debian in a > very short time. If, however, the upstream source contains "significant > improvements" to the way the software is built (i.e., it has extensive > changes), then don't expect anything from me before the middle of > September. > Why not ask for help and/or co-maint? We are going into mainstream towards sarge releasing, so you couldn't have sufficient time for usual release-test cycle of a new upstream release. -- Francesco P. Lovergine
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Adam Heath <[EMAIL PROTECTED]> wrote:
>
> On Wed, 27 Aug 2003, Ean R. Schuessler wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> Format: 1.7
>> Date: Wed, 27 Aug 2003 17:18:37 -0500
>> Source: kaffe
>> Binary: kaffe
>> Architecture: source i386
>> Version: 1:1.1.1-1
>> Distribution: unstable
>> Urgency: low
>> Maintainer: Ean R. Schuessler <[EMAIL PROTECTED]>
>> Changed-By: Ean R. Schuessler <[EMAIL PROTECTED]>
>> Description:
>> kaffe - A JVM to run Java bytecode
>> Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021
>> 170059 193263 196254 196867 197617 200434 202779
>> Changes:
>> kaffe (1:1.1.1-1) unstable; urgency=low
>> .
>>* New upstream release closes many bugs. (Closes: #51230, #61264,
>> #75800, #77869, #116802, #141597, #158743, #170021, #170059,
>> #193263, #196254, #197617, #202779, #81389, #200434, #196867)
>>* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936)
>
> This is not a proper changelog entry.
>
> A proper entry is as follows:
>
> * New upstream release.
> * no longer does foo when bar happens. Closes: #12345
> * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345
>
> Please, everyone remember, a changelog documents *changes*. It's not a tool
> to close bugs automatically.
This is bullshit.
We've gone through this many times already. Upstream changes should
not be documented in the Debian changelog, even if they fix bugs in
the Debian BTS.
If I were the maintainer of this package, I would close these bugs again.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Friday 29 August 2003 09:28, Steve Lamb wrote: > On Fri, 29 Aug 2003 00:36:57 -0700 > > Adam McKenna <[EMAIL PROTECTED]> wrote: > > Well, since we're pointing fingers, it's really SMTP that's broken by > > design, and all anti-spam programs (including C-R systems) are merely > > stopgap measures that try to make up for SMTP's shortcomings. > > Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. exacerbate is probably what you meant here. ben
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: > > We've gone through this many times already. Upstream changes should > > not be documented in the Debian changelog, even if they fix bugs in > > the Debian BTS. > > Because users that submitted bugs using the Debian BTS do not deserve > the right to get a mail meaningful about the bug they reported? "The bug has been fixed" is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 08:59:04PM -0700, Joshua Kwan wrote: > On Fri, Aug 29, 2003 at 01:51:58PM +1000, Russell Coker wrote: > > > It's a bit extreme but I'm sick of deleting such messages, especially in > > > light of the Blaster worm. > > > > Not extreme at all. > > I imagine there are some legitimate people I might receive emails from, > reply to them and never know it didn't get sent. That's my only problem > with this approach, although it would be possible to tell procmail to > stick C-R responses into some special folder... Do you *really* want to converse with people so clue-adverse that they don't whitelist people they send mail to? I don't think I'd want to. Might catch some of that stupidity. Lord knows I suffer enough already. - Matt
