Bug#573816: Font size has shrunk during package upgrade
> > After upgrading to this version of ktorrent as part of an apt upgrade, > > all application fonts are now approx 6pt (maybe not 6pt, but not much > > more) font, making the display almost unreadable. All application fonts > > for the system are set to 12pt, but ktorrent (after the upgrade) is the > > only app using 6pt. > > > > A quick google for this problem shows others who have had the problem, > > but with no solutions offered. > > From which version did you upgrade? ktorrent 2.2.x (lenny)? Preparing to replace ktorrent 2.2.2.dfsg.1-1 (using .../ktorrent_3.3.4 +dfsg.1-1_amd64.deb) > And by "All application fonts for the system" you mean System Settings -> > Appearance -> > Fonts? If I go into System -> Preferences -> Appearance and select the Fonts tab, all listed fonts are fontsize 12. >From my reading of the problem it appears to be KDE-related, as ktorrent appears tightly woven into KDE. I use ktorrent but under a primarily gnome-based sysetm, which may be the problem that some KDE component which is required is missing. See http://dvaey.homeip.net/fonts.jpg for example. In the photo you can see my gnome-panel menu and evolution use the same font size, while ktorrent uses a smaller font. Ive read on other forums to use kde tools to change settings, however as I use gnome, I dont have the KDE control panel installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573816: Font size has shrunk during package upgrade
Package: ktorrent Version: 3.3.4+dfsg.1-1 After upgrading to this version of ktorrent as part of an apt upgrade, all application fonts are now approx 6pt (maybe not 6pt, but not much more) font, making the display almost unreadable. All application fonts for the system are set to 12pt, but ktorrent (after the upgrade) is the only app using 6pt. A quick google for this problem shows others who have had the problem, but with no solutions offered. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507212: mplayer issues spurious messages
This bug is also in mplayer version 1.0~rc2+svn20090303-2, and has been in every version since I submitted this bug (mid 2008), whether or not a specific subversion has been in unstable or not, the bug has existed since mid 2008 as evidenced by the package name in my original submission. On Wed, 2009-03-11 at 23:25 +0100, Reinhard Tartler wrote: > severity 507212 wishlist > stop > > David Murn writes: > > > Package: mplayer > > Version: 1:1.0rc2svn20080706-0.1 > > this version has never been in unstable. Please consider filing such > bugs at the actual package maintainer or even better straight to > upstream. > > > Ive noticed lately, files that previously played fine under mplayer and > > now generating a huge amount of debug messages about vfw-avi frames. > > The actual message is: > > > > [mpeg4 @0xa389c0]Invalid and inefficient vfw-avi packed B frames > > detected > > Does this message go away when you use the switch -quiet? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505302: Caret browsing cannot be disabled
Package: iceweasel Version: 3.0.3-3 Severity: minor When the F7 key is accidently hit while firefox has the focus (for example when using Alt-F7 to switch to the X virtual console), firefox tries to toggle the caret browsing feature. The first time this happens a dialog box is presented which asks if you wish to turn caret browsing on or off, and also has a checkbox for 'do not show this window again'. If you tick the checkbox and try to turn off caret browsing, the next time the browser catches the F7 it will present the dialog box again. The 'dont show this window again' checkbox seems to only be recognized if caret browsing is turned on, in which case you can easily toggle it on and off with a press of the F7 key. However, I dont wish to use this feature, and would rather that it didnt pop up a dialog box everytime I flip to my X virtual console. If the user ticks the checkbox, the user is saying they dont want the window again, yet firefox keeps presenting the window until the user both ticks the checkbox and enables the caret mode. IMHO, this is wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507212: mplayer issues spurious messages
Package: mplayer Version: 1:1.0rc2svn20080706-0.1 Ive noticed lately, files that previously played fine under mplayer and now generating a huge amount of debug messages about vfw-avi frames. The actual message is: [mpeg4 @0xa389c0]Invalid and inefficient vfw-avi packed B frames detected This message is printed for every 2-3 seconds of video. While I understand the importance of this information to some users, to the average user this simply means the .xsession-errors file(s) get filled with spurious output that the average user is never going to see. This is only a recent change, and presumably a deliberate change to point out broken vfw-avi files. What option does someone have with this file, either put up with all the thousands of warnings, or re-code the file and still have to put up with warnings during the encoding instead. The files obviously arent too 'broken', since mplayer seems to play and encode them without missing a beat, but it is annoying seeing debug messages constantly in my log files and terminals, depending on how I use the app. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#542836: Caret browsing cannot be disabled
Package: iceweasel Version: 3.0.9-1 As a result of another unrelated bug, when I use Alt-F7 to switch from text mode back to X, the F7 key is passed through to firefox, which activates the caret browsing feature. Each time this key is pressed a box is displayed asking if you wish to turn caret browsing on. This dialog has a 'do not show this box again' checkbox, however if I tick the checkbox then click 'no' to not turn caret browsing on, and press F7 again the dialog is shown again. The only way to make the dialog box not appear, is to click the checkbox and then enable caret browsing. This then means all future F7 keypresses will silently enable caret browsing, with no indication to the user. I consider this a bug, as the indicated function of not showing the dialog box, is ignored. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543210: Alt-F7 to return to X, passes F7 key to top focus'd window
Package: xserver-xorg Version: 1:7.4+4 When Im in text console, using Alt-F7 to return to X passes the F7 key to the window which has current focus. Ive found numerous reports of this bug in other places via google, but no solutions or possible remedies to fix it. When watching the flow with xev, when I press Ctl and Alt the KeyPressed event is sent, then a KeyRelease is generated for both keys, just before the console switch occurs. When I press Alt-F7 to return, xev shows the F7 key appearing as a KeyPresed/KeyRelease'd event. Is there any way to prevent this key from reaching the X server? This bug has been reported in SuSE at the following URL.. https://bugzilla.novell.com/show_bug.cgi?id=141443 This page indicates that the bug has been resolved, but there appears to be no actual details of a resolution. This bug seems difficult to reproduce, as it doesnt occur on a fresh debian install, however my system was installed about 3 years ago and kept up-to-date ever since. I have updated all packages current as of 23/8/09, and the bug is still present. Im happy to provide any logs or other detailed debugging info to help resolve this issue, however Im somewhat over my head when it comes to debugging the X system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#359714: 'Swarm average' in global statistics
Package: azureus Version: 2.3.0.6-3 Severity: minor Azureus 2.3.0.6 added a 'feature' where the average swarm speed is shown on the global statistics page, however often when I try to view the stats, the 'average' line is sitting at about the middle of the graph, while the blue graph for my download speed, is relegated to a tiny section at the bottom. Often my swarm average speed moves anywhere from 50-200k/sec, where my download speed has a max of ~50k/sec. This means that the scale on the right, has steps at 50k so if my download speed drops by 10k/sec, its barely noticable on the graph. It would be nice if it was possible to NOT display the average speed, or at the very least, to modify the code so that the scale of the graph is only calculated based on the actual download speed, rather than the potential download speed the program believes it should get (which happens to be twice the average). I would downgrade to an earlier version which doesnt have this problem, however the 2.3.0.6 upgrade completely rewrote the config files, making a downgrade impossible. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355436: Cleaning /tmp should be optional
Package: initscripts Version: 2.86.ds1-12 Severity: important Like many others Im sure, I use my /tmp partition for storing files that I dont necessarily want to keep forever, but may for a short period of time. As such, I edited my bootclean.sh script, and commented out all code referring to /tmp. For maybe 6 months this system worked well, until I recently performed a dist-upgrade and the initscripts package was updated. Part of this update, overwrote my modified script, then proceeded to delete approximately 100mb of debs and other files that I had backed up from another server I was upgrading. In all, I lost approximately 200mb of data. Now, while I can understand in a pristine environment, for users who dont understand what they're doing, keeping /tmp clean, is a good idea, but for advanced users, generally we know what we're doing and dislike things happening that we dont know about. Ive got 2 points to raise on this issue. Firstly, a new init script should never be installed without first checking if the previous script has been modified. Apt did try to modify several scripts (most of which I disallowed as I have made major modifications to them), but I received no warning at all about bootclean being modified. Not only did apt trash all my data in /tmp, but it also trashed all changes I made to the script to stop it trashing /tmp in the first place. As a second thought to this, it would be nice if as part of the install process, if the user was asked if they want the script to blindly delete files on every startup. Im sure Im not the only person who downloads files temporarily (especially large debian archives) to /tmp. Maybe this could be added as part of the debconf system for advanced users. While I can understand the reasoning behind it, the mere fact that a debian script can blindly delete an entire directory is incredibly scary to me, as a user. Although it meets the criteria for a 'grave' bug (causing user data loss), I have only given it a tag of 'important', as it is only one part of the package which is troublesome. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310411: 'Pieces' progress bar disappears when I scroll away from left edge
Package: azureus Version: 2.3.0.0-3 Severity: minor I have my main display setup showing (in order): Health, #, Name, Size, Downloaded, Remaining, Done, Pieces, Availability, Down Speed, ETA, Up Speed, Status, Seeds, Peers, Tracker Status, and Share Ratio. When the matrix is completely to the left, the display is fine, however as soon as I scroll slightly to the right (even a single pixel), the graphical 'pieces' column disappears. Sometimes it only affects the currently affected line, while other, times every 'pieces' progress bar on the screen disappears. Even if they dont disappear immediately, they usually disappear within a couple of seconds. They return one-by-one, once I slide the horizontal scroller back fully left. This bug has been present since at least 2.1.0.4, in the Linux version, however under Windows this problem does not occur. I am using debian sun-j2re-1.5, but the bug was present when using 1.4 as well. The bug is generally 100% reproducable on my system. I tried to report this bug on sourcefag, but I dont wish to sign up, simply to report bugs, so hopefully some debian folk might be able to sort it out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343976: History file is saved with incorrect size
Package: bash Version: 3.0-17 For quite a while now Ive noticed a bug in bash failing to save the history file correctly. I often find that a history of 500 lines simply isnt enough, so I have edited my .bashrc to set HISTSIZE and HISTFILESIZE to 5000. However this does not appear to make any difference, as the .bash_history file seems limited to 500 lines (actually, 505 lines at ~9k). Even checking that both environment variables are set to 5000. Are there any instances in the bash source where these values are hard-coded, or even referenced? This bug has been present for well over a year, and finally annoyed me enough to report it. I can help provide any further information necessary to help investigate this issue, but it seems to be 100% reproducable on several machines I have, running different versions of bash. David Murn David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343976: Acknowledgement (History file is saved with incorrect size)
Upon digging a little further (I really shouldve done this before submitting the first report), I have discovered what I think may be the problem. When I logout, bash saves the complete history (upto HISTSIZE lines) to the .bash_history file, however the problem occurs when bash starts up. It sets up its environment, setting HISTSIZE to 500, then reads in (at most) 500 lines from the .bash_history file. It then processes the .bashrc and HISTSIZE is set to 5000, but by then the history has already been truncated to the initial value of 500 lines. There are a couple of solutions I can see to this.. 1) Read in the .bash_history file upon startup, upto EOF. Once completed, set HISTSIZE to the number of lines read from the file. This has a problem that you are reading an unknown number of lines, so may need some upper limit set. 2) Process the .bashrc file before reading in the .bash_history file, so that if the user does wish to change these values, it is possible. This would seem to be the easiest option, however I have not looked too in-depth at how this could be accomplished. David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335923: Tool-tips always stay on top
Package: azureus Version: 2.3.0.4-3 Severity: minor When the mouse pointer is over a tab (for example 'My Torrents') and the tool-tip pops up, if I switch to another window (with alt-tab, im using metacity for my wm), the tool-tip remains on top of every window. If I then move the mouse, the tool-tip remains in place. The only way to get rid of it, is to switch back to azureus and then move the mouse to activate another (or same) tool-tip, then move the mouse off the sensitive area, and the tool-tip will disappear. The tool-tip should be removed as soon as azureus window loses focus, and at the very least, it should be drawn on the azureus window, and not placed on top of all other windows on the desktop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331409: job control often doesnt work
I have seen similar things happen here. Often in my case, it tends to happen after Ive spawned more than one process from an xterm. Sometimes, I can run a program from within an xterm, continue using that terminal for some time, then if/when I close the xterm, sometimes every process it started will terminate too. This is intermittent though. If I start a process, for example with "opera &", then hit Ctl-D, then opera stays running. However if I start the process, then edit a couple of files, move some files/directories, etc (general usage), then close the xterm, then opera will close too. This problem has only persisted for me in X so far, however I just experienced it in console mode too. I had started a program (junkbuster) running as a background process, then went to edit a file. After I quit vi, I had lost my controlling terminal. strace on the bash process showed it sitting wait()'ing for something (not sure what) to return. I killed junkbuster, and my prompt came back. I then re-ran junkbuster with the previous command, it started properly, and returned me to a prompt. I have also had another instance, when I had a loop running.. basically $ while ( sleep 5s ); do ls ; done When I hit Ctl-C, the loop stopped, bash silently crashed, and I was returned to a login prompt. In the past, hitting Ctl-C sent a SIGINT to the 'sleep' process, which then caused 'while' to fail and return to a bash prompt. These bugs have only appeared (for me), with the change to 3.0-16 Hope this helps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310411: Broken 'pieces' bar
Okay, I think I might have just figured out the case-breaker. The amount the bar loses, is directly proportional to how far the scrollbar is, from the left edge. For example, if the scroll bar is 5 pixels away from the edge, then the top 5 pixels of the progress bar are missing. This can be very easily seen if you have the 'pieces' bar extended from the center of the window, and large enough to stretch past the right edge of the window. As you (very) slowly scroll away from the left-most edge, you will see the progress bar taper off in a 45-degree angle, as such: ###\ This means there must be a 1:1 relationship between the value of the scroll bar, and the number of pixels of the pieces bar that are visible, or rendered to the screen. On a 'pieces' bar, with a percentage indicator in the top 2 pixels (as used on the 'my torrents' page), if I move 1 pixel to the right, the top row of pixels in the percentage indicator disappear. By the time I reach 4-5 pixels across, the percentage bar has completely disappeared, and its starting to eat into the 'pieces' bar. Hopefully this direct (and partial) cause of the problem may help someone familiar with the code find the bug much faster. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337218: Blocking users with bad requests
Package: valknut Version: 0.3.7-2 Ive had problems recently with users requesting obsolete/incorrect files. Over the months/years my share has be rearranged many times, and some users who have old file lists or old search matches, believe I still have these files. By looking under the 'Log' tab in the Transfers window, I can see several (often 5-10 a minute) requests for files, which dont exist, yet these users keep requesting over and over again. This is an example of what shows in the log: [17:23:13] [nickname] Client: DC++ (0.674) [17:23:17] [nickname] Upload: [filename.avi] (347137/0) [17:23:17] [nickname] Upload (File not found): [filename.avi] [17:23:18] [nickname] Disconnected from 81.235.131.152:1962 It would be nice to be able to block these users from connecting, after receiving a certain threshold of requests. (eg. once 5 not-found replies are generated, ban the user from connecting). Ideally the solution would be to fix the faulty clients, but for an easy fix, it would make sense to block users generating fake requests. Not the least of which, is the resources (connection space/fd, slots, etc) that are used in dealing with these spurious requests. David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310411: more subtleties
Ive just realised another little subtlety with bits going missing in Azureus. If you have the health emoticon showing on the screen (as per default), if you scroll away from the edge, the corresponding number of pixels disappears from the top of the icon. This more clearly defines the error occuring with the progress bars, for the following reasons... 1. The bug affects all graphical drawable areas (eg. images, emoticons, as well as progress/pieces bars) 2. This method reveals that the top lines of the image are indeed being erased, rather than the alternative of images being offset incorrectly when drawn. This bug seems easily reproducable, in a number of circumstances, so hopefully with a bit more digging, a fix should be found. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338305: Context menu shortcut key conflict
Package: azureus Version: 2.3.0.4-3 Severity: wishlist In the context menu (right click) of a downloading file in 'My Torrents', both the menu items 'Publish' and 'Stop' use the same shortcut key 'p'. Can I suggest either the Publish key be changed to the 'u' or the Stop key changed to the 'S'? Ive listed this as wishlist since it is such a minor bug, but it can affect usability to a very minor extent. David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271307: Anti-spam still evadable by spammers
Hello, I reported this bug about 6 months ago, and didnt even get a response (other than all automated acknowledgements). Hopefully this time someone might have some advice on a fix, as Im sure I am not the only person getting hammered with spam on centericq. The problem arises through the anti-spam option not blocking 'authorization' messages. While this by itself isnt a big pain, the problem is that many spammers request authorization or send a 'denied authorization' packet, with their spam message attached as the 'reason to add' or 'reason for denial'. I quite often return to my computer after an extended period to find several of these messages, usually coming in groups of 3 or 4, (which have both requests and denials, and would probably show other messages if I didnt have anti-spam option on). I have had a look through the source, but unfortunately OOP is not my strongpoint, and the bug would be fixable in a few seconds by someone who knows where to look. Heres hoping I dont find myself emailing about ongoing spam in another 6 months too. Davey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313157: Transfers just dont work
Package: valknut Version: 0.3.7-1 Severity: normal After holding off on changing over to valknut for as long as I could (until debian forced me to change), I now find my concerns werent unfounded. Since changing to valknut, a lot of my transfers (not sure exactly how many, but Id say over half) are being blindly dropped by the client. After looking in the 'log' section of transfers, I often see things like "Warning: Remote wants to upload a file". Why is this a warinng? I requested the file, its in my queue, but for some reason valknut thinks that someone trying to send me the file, is worthy of a warning and closing the connection. There doesnt seem to be any pattern to this, as sometimes I might receive this 'warning' several times on a user, before the connection eventually starts and downloads. Is there any way to turn off this 'warinng', so the program functions as it was intended to? David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314283: Upload limiting ratio?
Package: azureus Severity: wishlist Ive recently had problems while running azureus that uploads sometimes out-balance downloads, sometimes by as much as 5:1. It would be nice to have a feature to restrict uploads on a pro-rata basis to downloads. As an example, one torrent Im downloading at the moment, has downloaded 10mb for the last 60mb it has uploaded. Ive tried limiting upload speed, however when I limit to say 5k/sec (for example), my download speeds are lucky to get over 2k/sec. While I understand limiting sharing is a feature that can be abused, having a client that only downloads 15-20% of what it uploads makes it pretty much useless as a downloading client. Some options to fix this problem, may be preventing share ratio from exceeding a certain amount, or allowing a correlation between up/down speed limiting, ie. dont upload at 10k/sec if youre only downloading at 100 byte/sec. (pretty much whats happening here) David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327589: QCad depends on non-existant library
Package: qcad Version: 2.0.4.0-1-2 Severity: grave With the apparent changeover from libqt3 to libqt3c102, qcad will no longer install properly (without wanting to install libqt3 and thus removing 200 other packages). The simple fix, is to make libqt3 have a 'Replaces' line, but until then, packages such as qcad must be re-created with a slightly changed 'depends' line to reflect this new qt3 library. Maybe this bug should be filed against libqt3 as a large myriad of packages are affected by it. Suggestions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310411: more subtleties
Im not sure if its related, but I just tried making the scrollable window a few pixels larger than the window, and I noticed when I scrolled to the right, the pieces bar stays intact, but the percentage bar at the top of the pieces bar (the solid line that grows from the left) disappears. So the pieces and percentage bar just above it, are both affected by this bug, but in slightly different ways. Hopefully this little tidbit might help someone looking into the problem. Unfortunately I know little about java programming, so Im out-of-my-depth trying to figure it out myself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327589: QCad depends on non-existant library
On Sun, 11 Sep 2005 19:39:03 +1000, Steve Langasek <[EMAIL PROTECTED]> wrote: Read the posts on the debian-qt-kde mailing list and the C++ ABI transition announcement on debian-devel-announce, which clearly explain that this is intended behavior. I am not subscribed to this mailing list, and if apt removing 200 packages to install qcad is 'intended behaviour' then I think maybe the bug should be reported in apt. If this is intended behaviour, then why is the bug fixable by a slight change to debian/control from qt3 to qt3c102, followed by a recompile? And my suggestion of adding a 'Replaces' line to various XXXc102 packages, would alieviate any of these problems, since I thought that was *EXACTLY* what it was made for.. when packages change name? Either way, why close this bug when it (as you acknowledge) still exists. Just because its 'intended behaviour' doesnt mean its not a grave bug. David Murn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412081: Viewing messages always jumps to EOF
Package: evolution Version: 2.6.3-3 Severity: minor When viewing mail in evolution, everytime a message is diaplyed, the window viewing the content of the message scrolls to the lower right corner of the message. This fault is nearly 100% reproducable, there are only rare occasions when the message is shown from the top (so headers are displayed). Infact, the only time I have seen this error not occur, was when I had a duplicate message in my inbox, and after jumping to the top of the first message, when I selected the duplicate from the inbox list, it displayed from the top. Also, slightly related, the 'official' bug reporting option in the help menu was completely broken, hence filing a debian bug against the package. This seems to happen with both text and HTML email, despite my having turned off every instance I can find to not display HTML content. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412081: Acknowledgement (Viewing messages always jumps to EOF)
Upon some more digging into this issue, it appears this effect isnt actually a bug, it was due to the 'Caret mode' being enabled in evolution for some reason. Im not sure if this is the default mode, however after a bit of googling, I managed to turn up a blog of someone reporting the same issue I reported, and reported it was fixable by unchecking the 'caret' option in the View menu. So the fact that the mail reader jumps to EOF isnt the bug, but maybe the bug is that caret mode is enabled as a default setting? Im not sure if Im able to test this, without completely deleting my data directory and removing and re-installing evolution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420491: Anti-spam feature is bypassable
Package: centericq Version: 4.21.0-19 Severity: wishlist This issue has been raised several times before, including I think by myself as a submitter. The issue is primarily to do with spam on the ICQ network. With the 'anti-spam' setting turned on, spam messages are blocked, however ICQ allows spammers to spam with an authorization request message. It would be nice in some way, to be able to control incoming messages, either on a message type (msg/auth) or protocol basis (icq/msn/jabber), from within the client. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
