Bug#988158: xscreensaver regularly crashes, leaving screen unlocked
Package: xscreensaver Version: 5.45+dfsg1-1 Severity: important X-Debbugs-Cc: da...@cornell.edu Dear Maintainer, As of a few months ago (after a dist-upgrade + reboot), sometimes when I come back to my desktop computer after leaving it alone for several hours, the screen is unlocked with xscreensaver no longer running (i.e. locking the screen no longer works until I run xscreensaver or xscreensaver-demo to restart it). I haven't noticed any pattern of when it happens other than the screensaver having been running for several hours, presumably undisturbed. Needless to say, the screen being unlocked without a password is a security issue, although admittedly a minor one for my setup. If I leave xscreensaver running in a console inside screen, I can see output like the following after a crash (no messages about it appear in dmesg): $ xscreensaver xscreensaver-systemd: 09:55:11: failed to connect as org.freedesktop.ScreenSaver: File exists xscreensaver: signal: 0: child pid 3281394 (xscreensaver-systemd) exited abnormally (code 1). xscreensaver: 09:55:22: ClientMessage ignored while authentication dialog is active xscreensaver: 09:55:30: no keyboard or mouse data in /proc/interrupts? xscreensaver: 12:05:53: ClientMessage ignored while authentication dialog is active xscreensaver: 15:36:23: ClientMessage ignored while authentication dialog is active xscreensaver: 19:11:55: ClientMessage ignored while authentication dialog is active XIO: fatal IO error 0 (Success) on X server ":0.0" after 1702519 requests (1702495 known processed) with 0 events remaining. $ X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 130 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Resource id in failed request: 0xe41bff8 Serial number of failed request: 23 Current serial number in output stream: 24 X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 130 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Resource id in failed request: 0xe41bffc Serial number of failed request: 23 Current serial number in output stream: 24 X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 130 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Resource id in failed request: 0xe41bffa Serial number of failed request: 23 Current serial number in output stream: 24 Apologies: the issue is sporadic, so I did not notice it immediately and therefore did not take note of exactly what the version numbers were before/after the issue started. Not sure it's related, but I'm using https://github.com/alexanderk23/gluqlo as my screensaver program and am using xscreensaver-command -watch to run some scripts on lock/unlock, based on the Perl script in the man page for xscreensaver-command in the -watch section. Let me know if there's any way I can collect more debugging information that may be useful. (Not sure what might be related; here's the versions of a few other packages that aren't listed explicitly as dependencies. I think all of them have been updated at least once since the problem started.) ii linux-image-amd64 5.10.28-1 amd64Linux for 64-bit PCs (meta-package) ii nvidia-kernel-dkms 460.73.01-1 amd64NVIDIA binary kernel module DKMS source ii xorg1:7.7+22 amd64X.Org X Window System -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.30-4 ii libcrypt11:4.4.18-4 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-1 ii libpam0g 1.4.0-7 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.3-5 ii libx11-6 2:1.7.0-2 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-1 Versions of packages xscreensaver recommends: ii libjpeg-turbo-progs 1:2.0.6-4 ii perl 5.32.1-3 ii wamerican [wordlist] 2019.10.06-1 ii xfonts-100dpi
Bug#981225: clementine: Clicking on seekbar is off by one pixel
Package: clementine Version: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1 Severity: normal Dear Maintainer, When hovering over the progress bar in the bottom-right, a tooltip shows what time will be seeked to. When actually clicking, the playback time is actually set to slightly earlier, apparently exactly the time shown by the tooltip when moving the mouse cursor one pixel to the left. Most of the time, this wouldn't even be noticeable, but when playing hour-long podcast episodes, that one pixel comes out to ~25 seconds. I end up just using keyboard shortcuts for the fine-tuning. I tried disabling the moodbar, but it made no difference. Possibly related, I am on a system with a 1.5x HiDPI monitor; I do not have window scaling enabled (as the options are 1x and 2x) but I do have custom DPI scaling (under xfce's settings Appearance->Fonts) set to 144. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clementine depends on: ii gstreamer1.0-plugins-base 1.18.1-dmo1 ii gstreamer1.0-plugins-good 1.18.1-dmo1 ii gstreamer1.0-plugins-ugly 1:1.18.1-dmo1 ii libasound2 1.2.3.2-1 ii libc6 2.30-4 ii libcdio19 1:2.1.0-dmo3 ii libchromaprint1 1:1.5.0-dmo1 ii libcrypto++88.4.0-1 ii libfftw3-double33.3.8-2 ii libgcc-s1 10-20200502-1 ii libglib2.0-02.66.2-1 ii libgpod40.8.3-15 ii libgstreamer-plugins-base1.0-0 1.18.1-dmo1 ii libgstreamer1.0-0 1.18.1-1 ii liblastfm5-11.0.9-1.1 ii libmtp9 1.1.17-3 ii libmygpo-qt5-1 1.1.0-4 ii libprotobuf23 3.12.3-2+b1 ii libpulse0 13.0-5 ii libqt5concurrent5 5.15.1+dfsg-2 ii libqt5core5a5.15.1+dfsg-2 ii libqt5dbus5 5.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5network5 5.15.1+dfsg-2 ii libqt5sql5 5.15.1+dfsg-2 ii libqt5widgets5 5.15.1+dfsg-2 ii libqt5x11extras55.15.1-2 ii libsqlite3-03.33.0-1 ii libstdc++6 10-20200502-1 ii libtag1v5 1.11.1+dfsg.1-3 ii libx11-62:1.6.12-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages clementine recommends: ii gstreamer1.0-pulseaudio 1.18.1-dmo1 Versions of packages clementine suggests: ii gstreamer1.0-plugins-bad 1:1.18.1-dmo2 -- no debconf information
Bug#954161: xfce4-pulseaudio-plugin: display active output port (i.e. headphones vs. speakers)
Package: xfce4-pulseaudio-plugin Version: 0.4.2-1 Severity: wishlist Dear Maintainer, In pavucontol, in the "Output Devices" tab, there's a drop-down labeled "Port" which tells me whether the output will go to "Line Out" (my speakers) or "Headphones". It changes automatically when I plug in/unplug my headphones, so I have no need of the changing the selection, but it would be nice if there were an option to display this information on the panel along with the volume. Thank you, Daniel -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-pulseaudio-plugin depends on: ii libc62.30-2 ii libglib2.0-0 2.64.1-1 ii libgtk-3-0 3.24.14-1 ii libkeybinder-3.0-0 0.3.2-1+b1 ii libnotify4 0.7.9-1 ii libpulse-mainloop-glib0 13.0-5 ii libpulse013.0-5 ii libwnck-3-0 3.32.0-1 ii libxfce4panel-2.0-4 4.14.3-1 ii libxfce4ui-2-0 4.14.1-1+b1 ii libxfce4util74.14.0-1 ii libxfconf-0-34.14.1-1 Versions of packages xfce4-pulseaudio-plugin recommends: ii pavucontrol 4.0-1 ii pulseaudio 13.0-5 xfce4-pulseaudio-plugin suggests no packages. -- no debconf information
Bug#954159: pavucontrol: allow multiple instances
Package: pavucontrol Version: 4.0-1 Severity: wishlist Dear Maintainer, The changelog on https://freedesktop.org/software/pulseaudio/pavucontrol/ for version 4.0 includes "There can now be only one pavucontrol window open at a time. Trying to start pavucontrol for a second time brings the first window to foreground.". This is a misfeature for the way I use pavucontrol. Previously, I would often have pavucontrol open on multiple desktops at once (e.g. I have a desktop for games and another one for TV streaming and want volume control on those two but not on others). (As this was called out in the upstream changelog, I don't really expect it to be changed, so some simple workarounds are (1) just set the window to show on all desktops or (2) make more use of the panel applet.) Thank you, Daniel -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pavucontrol depends on: ii libatkmm-1.6-1v5 2.28.0-2 ii libc62.30-2 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgcc-s1 [libgcc1] 10-20200312-2 ii libgcc1 1:9.2.1-9 ii libglib2.0-0 2.64.1-1 ii libglibmm-2.4-1v52.62.0-1 ii libgtk-3-0 3.24.14-1 ii libgtkmm-3.0-1v5 3.24.2-1 ii libpulse-mainloop-glib0 13.0-5 ii libpulse013.0-5 ii libsigc++-2.0-0v52.10.2-1 ii libstdc++6 10-20200312-2 Versions of packages pavucontrol recommends: ii pulseaudio 13.0-5 pavucontrol suggests no packages. -- no debconf information
Bug#787041: xfce4-panel: scrollwheel on pager to switch desktops doesn't wrap
Package: xfce4-panel Version: 4.12.0-2 Severity: normal File: /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libpager.so Dear Maintainer, The Workspace Switcher (pager) panel plugin has the option Switch workspaces using the mouse wheel which behaves similar to the option in the Window Manager Tweaks-Workspaces setting Use the mouse wheel on the desktop to switch workspaces except it does not respect the option found there Wrap workspaces when the first or the last workspace is reached. Either the behavior should be updated to be consistent or, if having the Workspace Switcher behavior depend on the Window Manager configuration, then a Wrap workspaces when the first or the last workspace is reached checkbox should be added to the Workspace Switcher settings. Expected behavior: scrolling up on Workspace Switcher when currently on the first desktop switches desktops to the last desktop. Observed behavior: nothing happens. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-panel depends on: ii exo-utils0.10.6-1 ii libatk1.0-0 2.16.0-2 ii libc62.19-18 ii libcairo21.14.2-2 ii libdbus-1-3 1.8.18-1 ii libdbus-glib-1-2 0.102-1 ii libexo-1-0 0.10.6-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgarcon-1-00.4.0-2 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libglib2.0-0 2.44.1-1 ii libgtk2.0-0 2.24.25-3 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libsm6 2:1.2.2-1+b1 ii libwnck222.30.7-2 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util74.12.1-2 ii libxfconf-0-24.12.0-2+b1 xfce4-panel recommends no packages. xfce4-panel suggests no packages. -- Configuration Files: /etc/xdg/xfce4/panel/launcher-8.rc 82b3d5da726357358e6976a9c3914a5b [Errno 2] No such file or directory: u'/etc/xdg/xfce4/panel/launcher-8.rc 82b3d5da726357358e6976a9c3914a5b' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779967: liferea: poor error reporting for command sourced feeds
To reproduce, create a new feed subscription where the source is a command which does not produce an RSS or ATOM feed. Any common command should display the behavior, say, /bin/ls or /bin/false. On Wed, Apr 22, 2015 at 1:40 PM, Marcelo Lacerda marceloslace...@gmail.com wrote: I'm curious, how do I reproduce this bug? On Fri, Mar 6, 2015 at 8:55 PM, Daniel Perelman da...@cornell.edu wrote: Package: liferea Version: 1.10.12-1 Severity: wishlist Dear Maintainer, When feeds generated by a command fail to produce a working feed, the error messages are both misleading and useless. Pretty much no matter what the problem is, it outputs: The last update of this subscription failed! There were errors while parsing this feed! Details Could not detect the type of this feed! Please check if the source really points to a resource provided in one of the supported syndication formats! XML Parser Output: The URL you want Liferea to subscribe to points to a webpage and the auto discovery found no feeds on this page. Maybe this webpage just does not support feed auto discovery.Source points to HTML document. You may want to contact the author/webmaster of the feed about this! (Strangely, that error even sometimes included saying that it got an HTTP 404 which makes no sense for a local resource.) My understanding is that once Liferea fails to parse an input as a feed, it tries to parse it as a webpage that has a link to a feed and it only reports the error for the second failure, despite the first failure almost always being the relevant one. As a workaround, using the same command as a conversion filter (not caring what the input being filtered is) gives more useful errors. In case that led to this bug report, telling me that the command was returning an exit code of 1 (although actually seeing the error message in output would have been more helpful). This is a very minor issue because in addition to the workaround just mentioned, I suspect this is a rarely used feature and except in edge cases like the one I ran into (it turned out the script worked with my bash environment variables but not with my X session's), simply running the command from a terminal would give the desired debugging information. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages liferea depends on: ii dbus-x11 1.8.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-peas-1.0 1.12.1-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-15 ii libcairo21.14.0-2.1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgirepository-1.0-11.42.0-2.2 ii libglib2.0-0 2.42.1-1 ii libgtk-3-0 3.14.5-1 ii libindicate5 0.6.92-2 ii libjson-glib-1.0-0 1.0.2-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libpeas-1.0-01.12.1-2 ii libsoup2.4-1 2.48.0-1 ii libsqlite3-0 3.8.7.4-1 ii libwebkitgtk-3.0-0 2.4.8-1 ii libxml2 2.9.1+dfsg1-4 ii libxslt1.1 1.1.28-2+b2 ii liferea-data 1.10.12-1 ii python-gi3.14.0-1 pn python:any none Versions of packages liferea recommends: pn gir1.2-gnomekeyring-1.0 none ii gnome-icon-theme 3.12.0-1 ii gnome-keyring3.14.0-1+b1 ii steadyflow 0.2.0-1.1 Versions of packages liferea suggests: pn network-manager none -- no debconf information
Bug#779967: liferea: poor error reporting for command sourced feeds
Package: liferea Version: 1.10.12-1 Severity: wishlist Dear Maintainer, When feeds generated by a command fail to produce a working feed, the error messages are both misleading and useless. Pretty much no matter what the problem is, it outputs: The last update of this subscription failed! There were errors while parsing this feed! Details Could not detect the type of this feed! Please check if the source really points to a resource provided in one of the supported syndication formats! XML Parser Output: The URL you want Liferea to subscribe to points to a webpage and the auto discovery found no feeds on this page. Maybe this webpage just does not support feed auto discovery.Source points to HTML document. You may want to contact the author/webmaster of the feed about this! (Strangely, that error even sometimes included saying that it got an HTTP 404 which makes no sense for a local resource.) My understanding is that once Liferea fails to parse an input as a feed, it tries to parse it as a webpage that has a link to a feed and it only reports the error for the second failure, despite the first failure almost always being the relevant one. As a workaround, using the same command as a conversion filter (not caring what the input being filtered is) gives more useful errors. In case that led to this bug report, telling me that the command was returning an exit code of 1 (although actually seeing the error message in output would have been more helpful). This is a very minor issue because in addition to the workaround just mentioned, I suspect this is a rarely used feature and except in edge cases like the one I ran into (it turned out the script worked with my bash environment variables but not with my X session's), simply running the command from a terminal would give the desired debugging information. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages liferea depends on: ii dbus-x11 1.8.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-peas-1.0 1.12.1-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-15 ii libcairo21.14.0-2.1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgirepository-1.0-11.42.0-2.2 ii libglib2.0-0 2.42.1-1 ii libgtk-3-0 3.14.5-1 ii libindicate5 0.6.92-2 ii libjson-glib-1.0-0 1.0.2-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libpeas-1.0-01.12.1-2 ii libsoup2.4-1 2.48.0-1 ii libsqlite3-0 3.8.7.4-1 ii libwebkitgtk-3.0-0 2.4.8-1 ii libxml2 2.9.1+dfsg1-4 ii libxslt1.1 1.1.28-2+b2 ii liferea-data 1.10.12-1 ii python-gi3.14.0-1 pn python:any none Versions of packages liferea recommends: pn gir1.2-gnomekeyring-1.0 none ii gnome-icon-theme 3.12.0-1 ii gnome-keyring3.14.0-1+b1 ii steadyflow 0.2.0-1.1 Versions of packages liferea suggests: pn network-manager none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632814: pidgin-libnotify: non-square buddy icons resized improperly
Package: pidgin-libnotify Version: 0.14-4 Severity: minor The icon shown in the notification is square and appears to be made by stretching the IMing user's icons to the full width and height of the space. As most icons are square this is fine, for non-square icons, this looks odd. The correct behavior would be to scale the icon to either the full width or full height of the space. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin-libnotify depends on: ii libatk1.0-0 2.0.1-1 ATK accessibility toolkit ii libc6 2.13-8 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.4.12-4 simple interprocess messaging syst ii libdbus-glib-1-20.94-4 simple interprocess messaging syst ii libfontconfig1 2.8.0-3 generic font configuration library ii libfreetype62.4.4-2 FreeType 2 font engine, shared lib ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libpango1.0-0 1.28.4-1 Layout and rendering of internatio ii pidgin 2.9.0-1 graphical multi-protocol instant m ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime pidgin-libnotify recommends no packages. pidgin-libnotify suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561865: pidgin-otr: Pidgin does not notify of new unencrypted messages while encrypting
Package: pidgin-otr Version: 3.2.0-5 Severity: wishlist While in private/unverified mode, if a new unencrypted message is received, then the following message appears: The following message received from $USERNAME was not encrypted: [$MESSAGE] It is good that OTR is very explicit and clear that the message is not encrypted. The problem is that Pidgin does not consider that a new message, instead it treats it like a status change (ex. user signed on), so no notification of the message is ever generated past the user's tab turning grey. This is an especially large problem if the user has switched to a computer which does not support OTR so they cannot attempt to start a new encrypted conversation which would generate new message notifications. Every new message, even unencrypted ones, should trigger Pidgin's message notification mechanisms. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin-otr depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libgcrypt11 1.4.5-1LGPL Crypto library - runtime libr ii libotr2 3.2.0-2Off-the-Record Messaging library ii pidgin2.6.4-1graphical multi-protocol instant m pidgin-otr recommends no packages. pidgin-otr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538644: pidgin-otr: Logging in from more than one computer confuses OTR
Package: pidgin-otr
Version: 3.2.0-4
Severity: normal
I use pidgin-otr on both my laptop and my desktop. Both are set to
automatically initiate private messaging. They have different OTR keys.
If I am logged into AIM or XMPP from both, then I often have troubles with
initiating and keeping private conversations, apparently because the other
computer attempts make its own private conversation. I get messages like
We received an unreadable encrypted message from {username}.
in the middle of a conversation or
Error setting up private conversation: Malformed message received
when trying to start a private conversation.
This problem does not always occur, which I suspect is due to the fact that
those protocols try to only send messages to the active computer, and only send
to all computers logged in when it does not know which computer is active. I
suspect the following is happening:
(1) The other person in the conversation sends a request to initiate a private
conversation.
(2) Both of my computers receive that and both reply to it.
(3) The other person's computer sees two private conversation confirmations in
a row and can't accept both.
My current work-around is simply to not be logged into IM with Pidgin on
multiple computers (which often involves ssh and killall pidgin).
For XMPP, it seems like having the OTR plugin be aware of resources would be
sufficient to fix this as every computer logged into a single XMPP account has
a different resource. This seems sub-optimal, as it ignores every other
protocol.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25.5 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pidgin-otr depends on:
ii libc6 2.9-6 GNU C Library: Shared libraries
ii libgcrypt11 1.4.4-2LGPL Crypto library - runtime libr
ii libotr2 3.2.0-1Off-the-Record Messaging library
ii pidgin2.5.5-1graphical multi-protocol instant m
pidgin-otr recommends no packages.
pidgin-otr suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
