Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> wrote: > The tag is not for whether the reporter can reproduce this, > but for whether the maintainer can. I can't. Please learn what the > tag is about before removing tags set by the maintainer. > > manoj
I'm sorry if you think I acted inappropriately, and I hope you will accept my apologies. It was certainly not my intention to interfere with ho you are maintaining the package. I definitely appreciate your effort in maintaining gnus, and think that it is well-maintained and that you are quite responsive to bug reports and so forth. Without detracting from this appreciation in any way, I might gently point out that you have perhaps misunderstood my post. It should be clear from my statement that I understand exactly what the tag is for. Please reread what I wrote: > I'm still getting exactly the same behavior with > 5.10.6-1.NO.20050809-2. I've removed the "unreproducible" tag from > this bug because I had earlier (after the tag was originally placed > though) included step-by-step instructions for reproducing the > problem with an uncustomized (beyond default debian stuff) > configuration. If you are not able to reproduce the problem > following those steps, please let me know and restore the > unreproducible tag. Thanks. I trust that your restoration of the unreproducible tag, exactly as I had suggested, indicates that you are unable to reproduce the bug using the exact sequence of steps I provided in my report. Is this correct? If it is, then there must be something deeply hidden in my environment since I have factored out any of my personal configuration in reproducing the bug. Please confirm that you have tried the exact sequence of steps I used to reproduce the problem and that you have still not seen it. Remember that you added the unreproducible tag before I posted my steps to reproduce the bug, so I had no way to know whether you had tried those steps. Also, please understand that my intention here is to help get this problem fixed, and not to interfere with the way you maintain the problem. If we're in a state where I can reproduce the problem and you can't, then the problem will never get resolved. To save you additional digging, here again are the exact steps: I am able to reproduce this problem by invoking emacs like this: xrdb -load /dev/null # Make sure there is no ~/.Xdefaults file emacs -q --eval="(setq-default show-trailing-whitespace t)" -xrm 'Emacs.toolBar: false' and then M-x gnus The first time gnus is run, the text-based logo shows up at first, and then is replaced by all whitespace, which is highlighted in red (i.e., shown in the trailing-whitespace face -- changing the face background color to something different from the gnus splash color still doesn't make the gnus logo visible). Subsequent times gnus is run, I just see the whitespace. If you are not able to reproduce the problem with these steps, I will come up with a sequence of steps that works in a chroot thus ruling out any local configuration problem, or I will discuss the problem directly with upstream. Thanks for your attention to this admittedly minor problem. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
