[Desktop-packages] [Bug 1681295] Re: Problem in nm-openvpn-service.c, openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache.
Patch fixes the problem entirely. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1681295 Title: Problem in nm-openvpn-service.c, openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache. Status in network-manager-openvpn package in Ubuntu: Confirmed Bug description: So I've been using OpenVPN through the network-manager-openvpn package integrated into the network manager GUI. I experienced an odd problem where consistently, during or after downloading (in this case, I tested by just downloading the kernel tarball from kernel.org repeatedly, which is around 90MB) Every single time, without fail, the openvpn client would fail and my connection would go dead. To reconnect, I would have to manually restart the network manager. Now, I played around with .conf files and the CLI openvpn client and noticed EXACTLY the same behavior happening. I eventually arrived to the conclusion that the flag or option "auth-nocache" would cause a connection reset after or during downloads and streaming. I then got to reading the openvpn man pages and I stumbled across this message (you can easily find it by going 'man openvpn | grep nocache') about the guaranteed failure of key renegotiation if auth-user-pass and auth-nocache were used together: " Further, using --daemon together with --auth-user-pass (entered on console) and --auth-nocache will fail as soon as key renego‐ tiation (and reauthentication) occurs." When I removed auth-user-pass from my .conf files, the problem went away. Then I wondered. Now what if...network-manager-openvpn was actually passing both flags to openvpn? Then I downloaded the source tarball and found that indeed, this exact thing is happening on a SINGLE line. See line 1380 of network-manager-openvpn-1.1.93/src/nm-openvpn-service.c "add_openvpn_arg (args, "--auth-nocache");" So I decided to comment out that single line. I then rebuilt the packages network-manager-openvpn and network-manager-openvpn-gnome using 'dpkg-buildpackage -us -uc -nc', installed them, and tested downloading the source kernel repeatedly to see if the connection would hold. It does! Literally commenting out ONE line fixed weeks worth of extreme annoyance repeatedly reconnecting to my vpn. This issue is rather annoying and needs to be fixed so openvpn doesn't keep cutting out. I've attached a patch for the source. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1681295/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1681295] Re: Problem in nm-openvpn-service.c, openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache.
Can this be marked as urgent? This is a *huge* problem! I can confirm the attached patch resolves disconnects every 10 minutes for me completely (been up 24 hours so far). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1681295 Title: Problem in nm-openvpn-service.c, openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache. Status in network-manager-openvpn package in Ubuntu: Confirmed Bug description: So I've been using OpenVPN through the network-manager-openvpn package integrated into the network manager GUI. I experienced an odd problem where consistently, during or after downloading (in this case, I tested by just downloading the kernel tarball from kernel.org repeatedly, which is around 90MB) Every single time, without fail, the openvpn client would fail and my connection would go dead. To reconnect, I would have to manually restart the network manager. Now, I played around with .conf files and the CLI openvpn client and noticed EXACTLY the same behavior happening. I eventually arrived to the conclusion that the flag or option "auth-nocache" would cause a connection reset after or during downloads and streaming. I then got to reading the openvpn man pages and I stumbled across this message (you can easily find it by going 'man openvpn | grep nocache') about the guaranteed failure of key renegotiation if auth-user-pass and auth-nocache were used together: " Further, using --daemon together with --auth-user-pass (entered on console) and --auth-nocache will fail as soon as key renego‐ tiation (and reauthentication) occurs." When I removed auth-user-pass from my .conf files, the problem went away. Then I wondered. Now what if...network-manager-openvpn was actually passing both flags to openvpn? Then I downloaded the source tarball and found that indeed, this exact thing is happening on a SINGLE line. See line 1380 of network-manager-openvpn-1.1.93/src/nm-openvpn-service.c "add_openvpn_arg (args, "--auth-nocache");" So I decided to comment out that single line. I then rebuilt the packages network-manager-openvpn and network-manager-openvpn-gnome using 'dpkg-buildpackage -us -uc -nc', installed them, and tested downloading the source kernel repeatedly to see if the connection would hold. It does! Literally commenting out ONE line fixed weeks worth of extreme annoyance repeatedly reconnecting to my vpn. This issue is rather annoying and needs to be fixed so openvpn doesn't keep cutting out. I've attached a patch for the source. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1681295/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1581745] [NEW] 3rd monitor can't display full-resolution with amdgpu and R9 380
Public bug reported: I have an AMD R9 380. This card under Windows displays full resolution (1920x1200x60) all 3 of my monitors perfectly. The connection setup is 2 x DVI, 1 Display Port with an active adaptor convered to DVI. Using AMDGPU, the 3rd monitor is properly detected, it's resolution is detected and the card attempts to drive it, but the monitor cannot sync the display signal and flickers endlessly trying to do so. Dropping the 3rd monitor resolution to 1650x1080x60 displays an image, but obviously not at full resolution. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg (not installed) ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: X-Cinnamon Date: Sat May 14 15:51:03 2016 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug rebecca resolution -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1581745 Title: 3rd monitor can't display full-resolution with amdgpu and R9 380 Status in xorg package in Ubuntu: New Bug description: I have an AMD R9 380. This card under Windows displays full resolution (1920x1200x60) all 3 of my monitors perfectly. The connection setup is 2 x DVI, 1 Display Port with an active adaptor convered to DVI. Using AMDGPU, the 3rd monitor is properly detected, it's resolution is detected and the card attempts to drive it, but the monitor cannot sync the display signal and flickers endlessly trying to do so. Dropping the 3rd monitor resolution to 1650x1080x60 displays an image, but obviously not at full resolution. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg (not installed) ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 CurrentDesktop: X-Cinnamon Date: Sat May 14 15:51:03 2016 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1581745/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 199167] Re: Owner changed after saving file
Confirmed for 13.04 as well. When logged into an SFTP share as root, if I edit a file by another user and hit save the file's permissions get reset to root:root. This is a very big problem editing web-pages or configuration files which might been specific ownerships and not be world-readable since they then can't be loaded. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/199167 Title: Owner changed after saving file Status in Geany: Unknown Status in Light-Weight Text Editor for Gnome: Confirmed Status in “geany” package in Ubuntu: Triaged Status in “gedit” package in Ubuntu: Triaged Bug description: Binary package hint: gvfs I've edited a text file with gedit via sftp. After saving it, the owner user and group is changed to the user that logged on the ssh server. This should not happen. To manage notifications about this bug go to: https://bugs.launchpad.net/geany/+bug/199167/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1105510] Re: [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups
** Attachment added: Xorg.0 log from kernel 3.5.0-22 https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1105510/+attachment/3500721/+files/Xorg.0.log.old -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1105510 Title: [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups Status in “xorg-server” package in Ubuntu: New Bug description: Upgrading to kernel 3.5.0-22 from 3.5.0-21 has broken my multiple monitor setup using the open-source radeon driver. My DVI monitor suffers from display corruption when booting, and can only run in mirror mode with my second VGA monitor. Plugging in only one monitor fixes the problem, but only allows the one display to be used. Booting into kernel 3.5.0-21 fixes all issues and everything operates normally. I believe this is related to kernel changes in the DRM/radeon drivers made upstream and first spotted in xorg-edgers a while back in #1093753, although the proposed commit patch there did not resolve all issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1105510/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1105510] Re: [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups
Kernel logs of booting with 3.5.0-22. The notable error message is: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! ** Attachment added: Kernel logs from 3.5.0-22. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1105510/+attachment/3500722/+files/kern.log -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1105510 Title: [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups Status in “xorg-server” package in Ubuntu: New Bug description: Upgrading to kernel 3.5.0-22 from 3.5.0-21 has broken my multiple monitor setup using the open-source radeon driver. My DVI monitor suffers from display corruption when booting, and can only run in mirror mode with my second VGA monitor. Plugging in only one monitor fixes the problem, but only allows the one display to be used. Booting into kernel 3.5.0-21 fixes all issues and everything operates normally. I believe this is related to kernel changes in the DRM/radeon drivers made upstream and first spotted in xorg-edgers a while back in #1093753, although the proposed commit patch there did not resolve all issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1105510/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1105510] [NEW] [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups
Public bug reported: Upgrading to kernel 3.5.0-22 from 3.5.0-21 has broken my multiple monitor setup using the open-source radeon driver. My DVI monitor suffers from display corruption when booting, and can only run in mirror mode with my second VGA monitor. Plugging in only one monitor fixes the problem, but only allows the one display to be used. Booting into kernel 3.5.0-21 fixes all issues and everything operates normally. I believe this is related to kernel changes in the DRM/radeon drivers made upstream and first spotted in xorg-edgers a while back in #1093753, although the proposed commit patch there did not resolve all issues. ** Affects: xorg-server (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1105510 Title: [radeon] regression from 3.5.0-22 from 3.5.0-21 for multi-monitor setups Status in “xorg-server” package in Ubuntu: New Bug description: Upgrading to kernel 3.5.0-22 from 3.5.0-21 has broken my multiple monitor setup using the open-source radeon driver. My DVI monitor suffers from display corruption when booting, and can only run in mirror mode with my second VGA monitor. Plugging in only one monitor fixes the problem, but only allows the one display to be used. Booting into kernel 3.5.0-21 fixes all issues and everything operates normally. I believe this is related to kernel changes in the DRM/radeon drivers made upstream and first spotted in xorg-edgers a while back in #1093753, although the proposed commit patch there did not resolve all issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1105510/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1077895] Re: seahorse modal dialog prevents using other password management applications
Upstream bug report made at: https://bugzilla.gnome.org/show_bug.cgi?id=688295 ** Bug watch added: GNOME Bug Tracker #688295 https://bugzilla.gnome.org/show_bug.cgi?id=688295 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to seahorse in Ubuntu. https://bugs.launchpad.net/bugs/1077895 Title: seahorse modal dialog prevents using other password management applications Status in “seahorse” package in Ubuntu: New Bug description: When doing an action such as running debuild for package signing, seahorse will pop-up a dialog to ask to unlock a GPG key if it has a password (but is not yet recorded in seahorse for whatever reason). seahorse uses a modal dialog for this request, which prevents the user from using another password management application such as Keepass to copy+paste the password into the dialog. It is not clear that a simple modal dialog is actually providing any enhanced security in this case (the dialog went unmodal on one invocation for unclear reasons), and there is no way to disable this functionality in seahorse itself. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1077895/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1077895] [NEW] seahorse modal dialog prevents using other password management applications
Public bug reported: When doing an action such as running debuild for package signing, seahorse will pop-up a dialog to ask to unlock a GPG key if it has a password (but is not yet recorded in seahorse for whatever reason). seahorse uses a modal dialog for this request, which prevents the user from using another password management application such as Keepass to copy+paste the password into the dialog. It is not clear that a simple modal dialog is actually providing any enhanced security in this case (the dialog went unmodal on one invocation for unclear reasons), and there is no way to disable this functionality in seahorse itself. ** Affects: seahorse (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to seahorse in Ubuntu. https://bugs.launchpad.net/bugs/1077895 Title: seahorse modal dialog prevents using other password management applications Status in “seahorse” package in Ubuntu: New Bug description: When doing an action such as running debuild for package signing, seahorse will pop-up a dialog to ask to unlock a GPG key if it has a password (but is not yet recorded in seahorse for whatever reason). seahorse uses a modal dialog for this request, which prevents the user from using another password management application such as Keepass to copy+paste the password into the dialog. It is not clear that a simple modal dialog is actually providing any enhanced security in this case (the dialog went unmodal on one invocation for unclear reasons), and there is no way to disable this functionality in seahorse itself. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1077895/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 225361] Re: .gvfs can't be stat'd by root causing backup tools to fail
On 12.10 this still appears to be an issue out of the box. The biggest problem it causes is that it makes working with one's own system very frustrating, since you lose the ability to use any GVFS mounted filesystems between sudo'd nautilus windows (you have to drag to local machine, then drag to wherever one is working). There desperately needs to be a configuration option for this. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/225361 Title: .gvfs can't be stat'd by root causing backup tools to fail Status in GVFS: New Status in “gvfs” package in Ubuntu: Triaged Status in “gvfs” package in ALT Linux: New Bug description: Problem === For security reasons ( possible DoS ), other users (esp. root) cannot access a fuse filesystem, and not even stat the mountpoint: $ sudo stat .gvfs stat: cannot stat `.gvfs': Permission denied $ sudo ls -la ls: cannot access .gvfs: Permission denied d? ? ? ? ?? .gvfs This means rsync --one-file-system (and similar options for find, tar...) cannot know this is a different file system they actually want to exclude, and fail on the permission denied error. Please note that it is GOOD AND CORRECT that root cannot copy the .gvfs directory. The real problem is that the stat fails. Workarounds === * bind-mount the file system you want to backup beforehand (see comment #67) See also === * Excellent description of the problem in bug 227724 * fuse-devel mailing list saying this will all be solved someday using private namespaces http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/3497/focus=3502 http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/7169/focus=7236 http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6197 (no answer at all) * Kernel documentation explaing the DoS http://www.kernel.org/doc/Documentation/filesystems/fuse.txt To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/225361/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 28052] Re: Improve mouse sensitivity and acceleration settings
The mouse settings on the Gnome Control Center are misnamed and misrepresentative. I suspect a lot of people are adjusting Sensitivity and expecting the pointer to get faster, but sensitivity is actually just the motion threshold before the Acceleration multiplier is applied - and none of this is explained in the UI. Acceleration needs to be renamed Pointer Speed or something. Sensitivity can then be left as is, since it'll make more sense in context. The other thing is that the Sensitivity slider is both backwards AND misrepresentative. It represents a value in pixels from 1 to 10, so huge parts of it's adjustment don't do anything. It needs to be notched so it's apparent it's a very limited integer representation. It also needs to be reversed - the common interpretation of a sensitive mouse is one which is twitchy - but adjusting sensitivity to high set's the motion- threshold to 10, which means the mouse is actually very slow since acceleration takes a lot of movement to apply. Finally, both of these sliders should probably have text input boxes next to them showing the exact numerical values they currently represent and allowing people to enter ones outside the current ranges - this would accomodate edge cases where it's not enough. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/28052 Title: Improve mouse sensitivity and acceleration settings Status in GNOME Control Center: Confirmed Status in X.Org X server: Fix Released Status in “gnome-control-center” package in Ubuntu: Triaged Bug description: In the mouse preferences dialog, I can adjust the acceleration just fine, but the sensitivity has no effet whatsoever. Whether I set it all to minimum or maximum, doesn't make teh slightest difference. I use a generic PS/2 mouse. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/28052/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
