[Desktop-packages] [Bug 2017365] [NEW] vanilla-gnome-desktop depends on pulseaudio which results in a conflict
Public bug reported: Installing vanilla-gnome-desktop on a fresh 23.04 install, fails with: The following packages have unmet dependencies: pipewire-alsa : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed pipewire-audio : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. ** Affects: ubuntu-gnome-meta (Ubuntu) Importance: Undecided Status: New ** Package changed: pipewire (Ubuntu) => ubuntu-gnome-meta (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pipewire in Ubuntu. https://bugs.launchpad.net/bugs/2017365 Title: vanilla-gnome-desktop depends on pulseaudio which results in a conflict Status in ubuntu-gnome-meta package in Ubuntu: New Bug description: Installing vanilla-gnome-desktop on a fresh 23.04 install, fails with: The following packages have unmet dependencies: pipewire-alsa : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed pipewire-audio : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-meta/+bug/2017365/+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 2017196] Re: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire-alsa conflicts with pulseaudio
I realize that the conflict is probably intended and my issue is that vanilla-gnome-desktop relies on pulseaudio still. I'll create a separate bug, sorry. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2017196 Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire- alsa conflicts with pulseaudio] Status in pipewire package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: Upgrading from UBUNTU 22.10 to UBUNTU 23.04 as advised. Required software appeared to have downloaded. Committing Changes operated to about 84% at which point the system crashed. It was necessary to re- initiate the upgrade procedure. This time, the upgrade proceeded to about 95% when an error notification appeared on the screen. Further upgrades were not attempted. ProblemType: Package DistroRelease: Ubuntu 22.10 Package: pipewire-alsa (not installed) ProcVersionSignature: Ubuntu 5.19.0-40.41-generic 5.19.17 Uname: Linux 5.19.0-40-generic x86_64 ApportVersion: 2.23.1-0ubuntu3.2 Architecture: amd64 CasperMD5CheckResult: unknown Date: Fri Apr 21 04:46:04 2023 ErrorMessage: conflicting packages - not installing pipewire-alsa:amd64 InstallationDate: Installed on 2020-02-04 (1171 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) Python3Details: /usr/bin/python3.10, Python 3.10.7, python3-minimal, 3.10.6-1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.18-9 RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.9ubuntu1 apt 2.5.3 SourcePackage: pipewire Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2017196/+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 2017196] Re: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire-alsa conflicts with pulseaudio
I seem to hit the same dep issues on a freshly installed 23.04 system when trying to install vanilla-gnome-desktop. The following packages have unmet dependencies: pipewire-alsa : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed pipewire-audio : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2017196 Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire- alsa conflicts with pulseaudio] Status in pipewire package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: Upgrading from UBUNTU 22.10 to UBUNTU 23.04 as advised. Required software appeared to have downloaded. Committing Changes operated to about 84% at which point the system crashed. It was necessary to re- initiate the upgrade procedure. This time, the upgrade proceeded to about 95% when an error notification appeared on the screen. Further upgrades were not attempted. ProblemType: Package DistroRelease: Ubuntu 22.10 Package: pipewire-alsa (not installed) ProcVersionSignature: Ubuntu 5.19.0-40.41-generic 5.19.17 Uname: Linux 5.19.0-40-generic x86_64 ApportVersion: 2.23.1-0ubuntu3.2 Architecture: amd64 CasperMD5CheckResult: unknown Date: Fri Apr 21 04:46:04 2023 ErrorMessage: conflicting packages - not installing pipewire-alsa:amd64 InstallationDate: Installed on 2020-02-04 (1171 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) Python3Details: /usr/bin/python3.10, Python 3.10.7, python3-minimal, 3.10.6-1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.18-9 RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.9ubuntu1 apt 2.5.3 SourcePackage: pipewire Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2017196/+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 1993594] Re: Scrolling in a view with many files is broken
Possibly related to https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1993594 Title: Scrolling in a view with many files is broken Status in nautilus package in Ubuntu: New Bug description: Scrolling up and down in a Files window, in a directory with many files, the scrolling is erratic and seems to often jump to the bottom of the view. It happens only when scrolling while hovering the actual files (eg. using the mouse wheel). If hovering the scrollbar instead, there are no problems. The problem is bad enough, it's basically useless to get things done. Problem happens both in List View and Grid View ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: nautilus 1:43.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Wed Oct 19 21:42:25 2022 GsettingsChanges: b'org.gnome.nautilus.icon-view' b'default-zoom-level' b"'large'" b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" b'org.gnome.nautilus.preferences' b'search-filter-time-type' b"'created'" b'org.gnome.nautilus.window-state' b'initial-size' b'(2179, 1167)' InstallationDate: Installed on 2022-05-20 (152 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: nautilus UpgradeStatus: Upgraded to kinetic on 2022-10-01 (18 days ago) usr_lib_nautilus: file-roller 43.0-1 nautilus-extension-gnome-terminal 3.46.2-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1993594/+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 1993594] Re: Scrolling in a view with many files is broken
** Attachment added: "Video showing problem. Using mouse wheel to ONLY scroll up." https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1993594/+attachment/5625351/+files/Screencast%20from%202022-10-19%2021-52-35.webm ** Bug watch added: gitlab.gnome.org/GNOME/gtk/-/issues #2971 https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1993594 Title: Scrolling in a view with many files is broken Status in nautilus package in Ubuntu: New Bug description: Scrolling up and down in a Files window, in a directory with many files, the scrolling is erratic and seems to often jump to the bottom of the view. It happens only when scrolling while hovering the actual files (eg. using the mouse wheel). If hovering the scrollbar instead, there are no problems. The problem is bad enough, it's basically useless to get things done. Problem happens both in List View and Grid View ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: nautilus 1:43.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Wed Oct 19 21:42:25 2022 GsettingsChanges: b'org.gnome.nautilus.icon-view' b'default-zoom-level' b"'large'" b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" b'org.gnome.nautilus.preferences' b'search-filter-time-type' b"'created'" b'org.gnome.nautilus.window-state' b'initial-size' b'(2179, 1167)' InstallationDate: Installed on 2022-05-20 (152 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: nautilus UpgradeStatus: Upgraded to kinetic on 2022-10-01 (18 days ago) usr_lib_nautilus: file-roller 43.0-1 nautilus-extension-gnome-terminal 3.46.2-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1993594/+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 1993594] [NEW] Scrolling in a view with many files is broken
Public bug reported: Scrolling up and down in a Files window, in a directory with many files, the scrolling is erratic and seems to often jump to the bottom of the view. It happens only when scrolling while hovering the actual files (eg. using the mouse wheel). If hovering the scrollbar instead, there are no problems. The problem is bad enough, it's basically useless to get things done. Problem happens both in List View and Grid View ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: nautilus 1:43.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Wed Oct 19 21:42:25 2022 GsettingsChanges: b'org.gnome.nautilus.icon-view' b'default-zoom-level' b"'large'" b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" b'org.gnome.nautilus.preferences' b'search-filter-time-type' b"'created'" b'org.gnome.nautilus.window-state' b'initial-size' b'(2179, 1167)' InstallationDate: Installed on 2022-05-20 (152 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: nautilus UpgradeStatus: Upgraded to kinetic on 2022-10-01 (18 days ago) usr_lib_nautilus: file-roller 43.0-1 nautilus-extension-gnome-terminal 3.46.2-1ubuntu1 ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug kinetic wayland-session -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1993594 Title: Scrolling in a view with many files is broken Status in nautilus package in Ubuntu: New Bug description: Scrolling up and down in a Files window, in a directory with many files, the scrolling is erratic and seems to often jump to the bottom of the view. It happens only when scrolling while hovering the actual files (eg. using the mouse wheel). If hovering the scrollbar instead, there are no problems. The problem is bad enough, it's basically useless to get things done. Problem happens both in List View and Grid View ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: nautilus 1:43.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Wed Oct 19 21:42:25 2022 GsettingsChanges: b'org.gnome.nautilus.icon-view' b'default-zoom-level' b"'large'" b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" b'org.gnome.nautilus.preferences' b'search-filter-time-type' b"'created'" b'org.gnome.nautilus.window-state' b'initial-size' b'(2179, 1167)' InstallationDate: Installed on 2022-05-20 (152 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: nautilus UpgradeStatus: Upgraded to kinetic on 2022-10-01 (18 days ago) usr_lib_nautilus: file-roller 43.0-1 nautilus-extension-gnome-terminal 3.46.2-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1993594/+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 1991493] Re: Data ciphers are not properly configured with openvpn 2.6
This update makes it possible to connect to VPNs where the "cipher" (now
"data-ciphers") option is needed, as long as the connection is manually
modified. This part works great.
The Gnome settings interface however, still looks for the "cipher"
option, so this part does not work. The settings interface cannot see
the specified data-ciphers setting and trying to set it from the
interface, sets the cipher option instead, rendering the connection
unusable.
--
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/1991493
Title:
Data ciphers are not properly configured with openvpn 2.6
Status in NetworkManager-OpenVPN:
New
Status in network-manager-openvpn package in Ubuntu:
Fix Released
Bug description:
OPTIONS ERROR: failed to negotiate cipher with server. Add the
server's cipher ('AES-256-CBC') to --data-ciphers (currently
'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to
this server.
So basically some servers won't be supported anymore because
unsupported '--cipher' option is used instead of '--data-ciphers'
A fix is available at https://gitlab.gnome.org/GNOME/NetworkManager-
openvpn/-/merge_requests/46
To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager-openvpn/+bug/1991493/+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 1987076] Re: Mouse cannot control windows after suspend and display change
lspci -k ** Attachment added: "lspci.txt" https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+attachment/5610691/+files/lspci.txt -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1987076 Title: Mouse cannot control windows after suspend and display change Status in mutter package in Ubuntu: Incomplete Bug description: My setup is this: Ubuntu: 22.04.1 LTS (Vanilla Gnome session on Wayland) Laptop: Lenovo ThinkPad P14s Gen 2a (AMD). Display: Lenovo T34w-20, connected via USB-C The problem started with upgrade to 22.04 I have had the same exact problem with my previous laptop, a ThinkPad T14s. Both of these are AMD laptops, but I had no problem on 21.10. Way I can usually reproduce (always?) 1. Suspend my laptop by yanking out the USB-C cable. 2. Resume the laptop by connecting a different monitor (same make and model, but not the same physical one) and hit the keyboard a few times. Note: Resuming on the same physical display does not seem to result in the same problem. After this, I can no longer control the Windows on my desktop. The mouse cursor is active, but moves behind the open windows, and mouse click is not registered (at least not in a way that is useful). I can navigate the windows and use the applications, using the keyboard. Ctrl+Alt+F1 to get to GDM, the mouse works fine. Going back the the real session, mouse is still "broken". Ctrl+Alt+F2 to get to a TTY, and going back to the original session, mouse is still "broken". Only way I have found to reliably restore functionality is a reboot (which I have been doing a lot of the last few months). Please let me know what else I can provide you with, in order to get this fixed. :) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: mutter 42.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Fri Aug 19 10:32:48 2022 InstallationDate: Installed on 2022-05-20 (91 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: mutter UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+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 1987076] Re: Mouse cannot control windows after suspend and display change
journalctl -b0 ** Attachment added: "journal.txt" https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+attachment/5610690/+files/journal.txt -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1987076 Title: Mouse cannot control windows after suspend and display change Status in mutter package in Ubuntu: Incomplete Bug description: My setup is this: Ubuntu: 22.04.1 LTS (Vanilla Gnome session on Wayland) Laptop: Lenovo ThinkPad P14s Gen 2a (AMD). Display: Lenovo T34w-20, connected via USB-C The problem started with upgrade to 22.04 I have had the same exact problem with my previous laptop, a ThinkPad T14s. Both of these are AMD laptops, but I had no problem on 21.10. Way I can usually reproduce (always?) 1. Suspend my laptop by yanking out the USB-C cable. 2. Resume the laptop by connecting a different monitor (same make and model, but not the same physical one) and hit the keyboard a few times. Note: Resuming on the same physical display does not seem to result in the same problem. After this, I can no longer control the Windows on my desktop. The mouse cursor is active, but moves behind the open windows, and mouse click is not registered (at least not in a way that is useful). I can navigate the windows and use the applications, using the keyboard. Ctrl+Alt+F1 to get to GDM, the mouse works fine. Going back the the real session, mouse is still "broken". Ctrl+Alt+F2 to get to a TTY, and going back to the original session, mouse is still "broken". Only way I have found to reliably restore functionality is a reboot (which I have been doing a lot of the last few months). Please let me know what else I can provide you with, in order to get this fixed. :) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: mutter 42.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Fri Aug 19 10:32:48 2022 InstallationDate: Installed on 2022-05-20 (91 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: mutter UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+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 1987076] Re: Mouse cannot control windows after suspend and display change
Thanks for the directions... It's not that hard to reproduce here, I just have to move between places (or I could bring my other monitor closer, for more intense troubleshooting if need be). But it just happened... There are no recent crashes and nothing reported by whoopsie. The requested files are attached. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1987076 Title: Mouse cannot control windows after suspend and display change Status in mutter package in Ubuntu: Incomplete Bug description: My setup is this: Ubuntu: 22.04.1 LTS (Vanilla Gnome session on Wayland) Laptop: Lenovo ThinkPad P14s Gen 2a (AMD). Display: Lenovo T34w-20, connected via USB-C The problem started with upgrade to 22.04 I have had the same exact problem with my previous laptop, a ThinkPad T14s. Both of these are AMD laptops, but I had no problem on 21.10. Way I can usually reproduce (always?) 1. Suspend my laptop by yanking out the USB-C cable. 2. Resume the laptop by connecting a different monitor (same make and model, but not the same physical one) and hit the keyboard a few times. Note: Resuming on the same physical display does not seem to result in the same problem. After this, I can no longer control the Windows on my desktop. The mouse cursor is active, but moves behind the open windows, and mouse click is not registered (at least not in a way that is useful). I can navigate the windows and use the applications, using the keyboard. Ctrl+Alt+F1 to get to GDM, the mouse works fine. Going back the the real session, mouse is still "broken". Ctrl+Alt+F2 to get to a TTY, and going back to the original session, mouse is still "broken". Only way I have found to reliably restore functionality is a reboot (which I have been doing a lot of the last few months). Please let me know what else I can provide you with, in order to get this fixed. :) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: mutter 42.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Fri Aug 19 10:32:48 2022 InstallationDate: Installed on 2022-05-20 (91 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: mutter UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+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 1987076] [NEW] Mouse cannot control windows after suspend and display change
Public bug reported: My setup is this: Ubuntu: 22.04.1 LTS (Vanilla Gnome session on Wayland) Laptop: Lenovo ThinkPad P14s Gen 2a (AMD). Display: Lenovo T34w-20, connected via USB-C The problem started with upgrade to 22.04 I have had the same exact problem with my previous laptop, a ThinkPad T14s. Both of these are AMD laptops, but I had no problem on 21.10. Way I can usually reproduce (always?) 1. Suspend my laptop by yanking out the USB-C cable. 2. Resume the laptop by connecting a different monitor (same make and model, but not the same physical one) and hit the keyboard a few times. Note: Resuming on the same physical display does not seem to result in the same problem. After this, I can no longer control the Windows on my desktop. The mouse cursor is active, but moves behind the open windows, and mouse click is not registered (at least not in a way that is useful). I can navigate the windows and use the applications, using the keyboard. Ctrl+Alt+F1 to get to GDM, the mouse works fine. Going back the the real session, mouse is still "broken". Ctrl+Alt+F2 to get to a TTY, and going back to the original session, mouse is still "broken". Only way I have found to reliably restore functionality is a reboot (which I have been doing a lot of the last few months). Please let me know what else I can provide you with, in order to get this fixed. :) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: mutter 42.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Fri Aug 19 10:32:48 2022 InstallationDate: Installed on 2022-05-20 (91 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: mutter UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: mutter (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy wayland-session -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1987076 Title: Mouse cannot control windows after suspend and display change Status in mutter package in Ubuntu: New Bug description: My setup is this: Ubuntu: 22.04.1 LTS (Vanilla Gnome session on Wayland) Laptop: Lenovo ThinkPad P14s Gen 2a (AMD). Display: Lenovo T34w-20, connected via USB-C The problem started with upgrade to 22.04 I have had the same exact problem with my previous laptop, a ThinkPad T14s. Both of these are AMD laptops, but I had no problem on 21.10. Way I can usually reproduce (always?) 1. Suspend my laptop by yanking out the USB-C cable. 2. Resume the laptop by connecting a different monitor (same make and model, but not the same physical one) and hit the keyboard a few times. Note: Resuming on the same physical display does not seem to result in the same problem. After this, I can no longer control the Windows on my desktop. The mouse cursor is active, but moves behind the open windows, and mouse click is not registered (at least not in a way that is useful). I can navigate the windows and use the applications, using the keyboard. Ctrl+Alt+F1 to get to GDM, the mouse works fine. Going back the the real session, mouse is still "broken". Ctrl+Alt+F2 to get to a TTY, and going back to the original session, mouse is still "broken". Only way I have found to reliably restore functionality is a reboot (which I have been doing a lot of the last few months). Please let me know what else I can provide you with, in order to get this fixed. :) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: mutter 42.2-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Fri Aug 19 10:32:48 2022 InstallationDate: Installed on 2022-05-20 (91 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: mutter UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1987076/+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 1973618] Re: can no longer open new windows after some time
I haven't been able to find other actual bugs/issues describing this issue, but there are threads on reddit and such that seem to indicate that this is a wayland/gnome42 issue, and that it affects all distributions. https://www.reddit.com/r/gnome/comments/ugpe12/firefox_on_gnome_42_cant_open_new_windows_after/ https://www.reddit.com/r/archlinux/comments/ugp9af/firefox_on_gnome_42_wayland_cant_create_new/ -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1973618 Title: can no longer open new windows after some time Status in Mozilla Firefox: New Status in firefox package in Ubuntu: Confirmed Bug description: After some time using firefox, I can no longer open a new window. => ps -ef | grep -c firefox 21 => /snap/bin/firefox => ps -ef | grep -c firefox 21 There is no new process created and the window never appears. I can open new tabs, but when I drag the tab to make it a new window, it is never created. The only remedy is to restart firefox. Sometimes I need to SIGTERM all of the zombi processes. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: firefox 1:1snap1-0ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30 Uname: Linux 5.15.0-27-generic x86_64 ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun May 15 19:45:08 2022 InstallationDate: Installed on 2021-10-12 (215 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) Snap.Changes: no changes found SourcePackage: firefox UpgradeStatus: Upgraded to jammy on 2022-04-22 (22 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1973618/+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 1947210] Re: Firefox Snap can't copy or drag in Wayland
Still a problem here. I'm on 22.04 with all updates (including proposed) installed, latest firefox snap (99.0-2, rev 1188). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1947210 Title: Firefox Snap can't copy or drag in Wayland Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Fix Released Bug description: I just upgraded to 21.10 Impish which supplies Firefox 93.0-1 via snap. I could not copy and paste to and from the browser. I logged out of Wayland and into Xorg and copy & paste works. Already reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1729901 so it's a known issue. I wanted to report it here so it gets into the Impish release notes or wherever along with the workaround. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1947210/+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 1886728] Re: OpenVPN OTP replaces the ordinary password
This is still an issue in Ubuntu 21.04 (development, as of March 30, 2021) It looks like people have been complaining about this for years, and while some people have tried to fix it, those fixes never made it in. Surely it must be of some type of urgency to support 2FA one-time passwords in the primary network management solution in Ubuntu? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1886728 Title: OpenVPN OTP replaces the ordinary password Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Triaged Bug description: When OpenVPN has One-time password (OTP) enabled, and the user connects, a dialog asks the user to enter the One-time password (OTP) and press ok. This action replaces the ordinary "long term" password with the OTP. This causes annoyance as the next login will fail because the password is wrong and the user has to enter both the password and the OTP the next time they log in. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-keyring 3.36.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jul 8 01:07:18 2020 InstallationDate: Installed on 2020-03-23 (106 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) SourcePackage: gnome-keyring UpgradeStatus: Upgraded to focal on 2020-05-11 (57 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1886728/+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 1918033] Re: gnome-shell crashed with Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (ac
I am no longer able to reproduce the crash after installing the proposed fix! Looks good to me! :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1918033 Title: gnome-shell crashed with Clutter:ERROR:../clutter/clutter/clutter- stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Status in mutter package in Ubuntu: Fix Committed Bug description: https://errors.ubuntu.com/problem/a9be8b5a5c0f1dc4f3be3c46a7ab42360c7a48c8 https://errors.ubuntu.com/problem/ea2e3b8ad662552e9123a94650b2045f3ea15d8c --- When clicking on the 'Clear' button in the notification panel, gnome- shell crashes. gnome-shell version: 3.38.3-3ubuntu1 Logs: Mar 07 11:34:04 yushijinhun-laptop gnome-shell[3639]: ** Mar 07 11:34:04 yushijinhun-laptop gnome-shell[3639]: Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Mar 07 11:34:04 yushijinhun-laptop gnome-shell[3639]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Mar 07 11:34:04 yushijinhun-laptop polkitd(authority=local)[635]: Unregistered Authentication Agent for unix-session:5 (system bus name :1.226, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) Mar 07 11:34:04 yushijinhun-laptop systemd[655]: org.gnome.Shell@x11.service: Main process exited, code=killed, status=6/ABRT Mar 07 11:34:04 yushijinhun-laptop systemd[655]: org.gnome.Shell@x11.service: Failed with result 'signal'. Mar 07 11:34:04 yushijinhun-laptop systemd[655]: org.gnome.Shell@x11.service: Scheduled restart job, restart counter is at 3. Mar 07 11:34:04 yushijinhun-laptop systemd[655]: Stopped GNOME Shell on X11. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu59 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 21.04 NonfreeKernelModules: nvidia_modeset nvidia Package: gnome-shell 3.38.3-3ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11 RelatedPackageVersions: mutter-common 3.38.3-3ubuntu1 Tags: third-party-packages hirsute wayland-session Uname: Linux 5.10.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip docker lxd plugdev sudo vboxusers wireshark _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1918033/+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 1918127] Re: gnome-shell crash when using panel
Problem occurs on Wayland as well as Xorg. Please let me know what kind of info you need. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1918127 Title: gnome-shell crash when using panel Status in gnome-shell package in Ubuntu: New Bug description: Whenever I perform an action in the Gnome Panel (Activate a VPN has 100% failure-rate, but I have seen it when clearing notifications and other things too), the entire session crashes and I'm back at login. I'm running gnome-session on Hirsute. journalctl /usr/bin/gnome-shell shows the following just before the crash: Mar 08 07:02:40 localhost gnome-shell[67382]: ** Mar 08 07:02:40 localhost gnome-shell[67382]: Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Mar 08 07:02:40 localhost gnome-shell[67382]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) The problem is 100% reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1918127/+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 1918127] [NEW] gnome-shell crash when using panel
Public bug reported: Whenever I perform an action in the Gnome Panel (Activate a VPN has 100% failure-rate, but I have seen it when clearing notifications and other things too), the entire session crashes and I'm back at login. I'm running gnome-session on Hirsute. journalctl /usr/bin/gnome-shell shows the following just before the crash: Mar 08 07:02:40 localhost gnome-shell[67382]: ** Mar 08 07:02:40 localhost gnome-shell[67382]: Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Mar 08 07:02:40 localhost gnome-shell[67382]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) The problem is 100% reproducible. ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: hirsute ** Tags added: hirsute -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1918127 Title: gnome-shell crash when using panel Status in gnome-shell package in Ubuntu: New Bug description: Whenever I perform an action in the Gnome Panel (Activate a VPN has 100% failure-rate, but I have seen it when clearing notifications and other things too), the entire session crashes and I'm back at login. I'm running gnome-session on Hirsute. journalctl /usr/bin/gnome-shell shows the following just before the crash: Mar 08 07:02:40 localhost gnome-shell[67382]: ** Mar 08 07:02:40 localhost gnome-shell[67382]: Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) Mar 08 07:02:40 localhost gnome-shell[67382]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-stage.c:3785:on_device_actor_reactive_changed: assertion failed: (!clutter_actor_get_reactive (actor)) The problem is 100% reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1918127/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
Never mind - Somehow my local package simply looked newer from a versioning perspective. I found the right version and as far as I can tell the problems are gone in this version. I have not seen any of the dbus messages and roaming works better (less erratic) here. Thanks a lot for getting this fix in. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Focal: Fix Released Bug description: * Impact extra roaming events are been generated * Test case check the output of `journalctl -lu wpa_supplicant`, it shouldn't have those warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
I've been looking for the package but cannot seem to find it for testing. Please help me find it and I will test it immediately. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Focal: Fix Released Bug description: * Impact extra roaming events are been generated * Test case check the output of `journalctl -lu wpa_supplicant`, it shouldn't have those warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
Thank you for taking care of this so swiftly. I don't believe I have much to add to the test-case. From testing locally I can see that the warnings disappear from the log and the connection _seems_ more stable. I underscore _seems_ because I have not been able to figure out which other parts of the system are actually using these particular dbus messages, if any. If nobody is actually using these, the perceived improvement could be placebo. I will keep testing though, because I've generally been struggling with a stable wifi connection on 20.04. Thanks again. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Committed Bug description: * Impact extra roaming events are been generated * Test case check the wpa_supplicant log, it should have warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] [NEW] dbus errors, frequent roaming and unstable connectivity
Public bug reported: When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: wpa (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: New Bug description: When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1852183] Re: [X11] copy/paste (clipboard) is broken in Ubuntu 19.10
On a fully updated Ubuntu 19.10, I feel most of my problems occur, when copying from a Wayland application, and pasting to an XWindow application. Most of the time, that doesn't work at all. As an example. Running my Firefox as a native Wayland application, I am experiencing problems copying a URL and pasting it into Chrome. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1852183 Title: [X11] copy/paste (clipboard) is broken in Ubuntu 19.10 Status in LibreOffice: Confirmed Status in Mutter: New Status in libreoffice package in Ubuntu: Triaged Status in mutter package in Ubuntu: Triaged Status in libreoffice source package in Eoan: Triaged Status in mutter source package in Eoan: Triaged Bug description: I'm running LibreOffice 6.3.2.2 on Ubuntu 19.10. In this environment, copy/cut/paste often fails. Specifically, the paste command sometimes does not paste the text that was cut/copied most recently. Instead, it pastes text that was cut/copied at some prior time. I use LibreOffice Writer a lot, and I now see this problem very often, i.e. many times every day. There is some discussion of the problem here: https://ask.libreoffice.org/en/question/213510/copypaste-issues- libreoffice-calc/ Several posters there say that they are also using Ubuntu 19.10. Ubuntu 19.10 includes Mutter 3.34, which has a new clipboard manager: https://www.phoronix.com/scan.php?page=news_item=GNOME-3.34 -Clipboard-Manager It seems like that could be related. To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1852183/+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 1614557] Re: Add support for Challenge/Response input
Looking through the code, these outputs may differ because of the different ways to authenticate... I'm not sure but both messages are certainly present in the latest openvpn code. FWIW, I'm connecting to an OpenVPN-AS solution with Certificates and Password -- 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/1614557 Title: Add support for Challenge/Response input Status in network-manager-openvpn package in Ubuntu: Fix Released Bug description: 2-factor authentication is all the rage these days, so we should to be able to prompt for the Challenge Response when needed... Right now the behaviour looks more like a password failure and it doesn't work (I'm on Gnome3). OpenVPN transaction that is probably what we need to look for is something along the lines of: "AUTH_FAILED,CRV1:R,E:lYxXoM3BLBcdnCytgqUoRn64c4y5b3BB:eHRoc3Q=:Enter PASSCODE" Prompt for "Enter PASSCODE" and submit that to openvpn and it should probably be it? The terminal openvpn client added similar support in 2.3.11 and it works. /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1614557/+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 1614557] Re: Add support for Challenge/Response input
Looks like the message that's being looked for might have changed: This is from my log now: AUTH: Received control message: AUTH_FAILED,CRV1:R,E:93NBZNaOH799HLoxv7tWefldc8JtIpbf:eHRod3Q=:Enter PASSCODE But based on the commit, it might be looking for: This is from the commit below: >PASSWORD:Verification Failed: 'Auth' ['CRV1:flags:state_id:username:text'] https://git.gnome.org/browse/network-manager- openvpn/commit/?h=1.2.10=5b96fecb97c752e08fdcebb331b983196f4b8935 -- 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/1614557 Title: Add support for Challenge/Response input Status in network-manager-openvpn package in Ubuntu: Fix Released Bug description: 2-factor authentication is all the rage these days, so we should to be able to prompt for the Challenge Response when needed... Right now the behaviour looks more like a password failure and it doesn't work (I'm on Gnome3). OpenVPN transaction that is probably what we need to look for is something along the lines of: "AUTH_FAILED,CRV1:R,E:lYxXoM3BLBcdnCytgqUoRn64c4y5b3BB:eHRoc3Q=:Enter PASSCODE" Prompt for "Enter PASSCODE" and submit that to openvpn and it should probably be it? The terminal openvpn client added similar support in 2.3.11 and it works. /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1614557/+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 1614557] Re: Add support for Challenge/Response input
This doesn't seem to work for me on Ubuntu 17.10: openvpn 2.4.3-4ubuntu1 network-manager 1.8.4-1ubuntu3 network-manager-gnome 1.8.4-1ubuntu3 network-manager-openvpn 1.2.10-0ubuntu2 network-manager-openvpn-gnome 1.2.10-0ubuntu2 When activating an OpenVPN connection that's challenge/response enabled, I'm prompted to reenter a password but it never works. The entered password is stored in the VPN definition as the primary password, so perhaps NM is reconnecting altogether rather than allowing me to pass the challenge response? -- 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/1614557 Title: Add support for Challenge/Response input Status in network-manager-openvpn package in Ubuntu: Fix Released Bug description: 2-factor authentication is all the rage these days, so we should to be able to prompt for the Challenge Response when needed... Right now the behaviour looks more like a password failure and it doesn't work (I'm on Gnome3). OpenVPN transaction that is probably what we need to look for is something along the lines of: "AUTH_FAILED,CRV1:R,E:lYxXoM3BLBcdnCytgqUoRn64c4y5b3BB:eHRoc3Q=:Enter PASSCODE" Prompt for "Enter PASSCODE" and submit that to openvpn and it should probably be it? The terminal openvpn client added similar support in 2.3.11 and it works. /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1614557/+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 1634208] Re: VPN cannot resolve DNS entries on second connect
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1634208 Title: VPN cannot resolve DNS entries on second connect Status in network-manager package in Ubuntu: Confirmed Bug description: Ubuntu 16.10 The first time I connect to a VPN (vpnc) everything works fine, but if I disconnect and then reconnect I can no longer resolve DNS entries although I can connect directly via IP address. The only solution seems to be a reboot. This was working fine in 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1634208/+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 1633003] Re: (Cisco) VPN name resolution breaks after upgrade to 1.2.2-0ubuntu0.16.04.3
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1633003 Title: (Cisco) VPN name resolution breaks after upgrade to 1.2.2-0ubuntu0.16.04.3 Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading my 16.04 installation today I noticed my VPN sessions suddenly had no name resolution anymore. Digging through /var/log/apt/history.log I noticed these were the updates: Start-Date: 2016-10-13 09:00:37 Commandline: apt dist-upgrade Requested-By: jeroenr (1000) Upgrade: libnm-glib4:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libsystemd0:amd64 (229-4ubuntu10, 229-4ubuntu11), libsystemd0:i386 (229-4ubuntu10, 229-4ubuntu11), libdbusmenu-glib4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), google-chrome-stable:amd64 (53.0.2785.143-1, 54.0.2840.59-1), libnm-glib-vpn1:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), udev:amd64 (229-4ubuntu10, 229-4ubuntu11), libnm0:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), network-manager:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libdbusmenu-gtk4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), kbd:amd64 (1.15.5-1ubuntu4, 1.15.5-1ubuntu5), libudev1:amd64 (229-4ubuntu10, 229-4ubuntu11), libudev1:i386 (229-4ubuntu10, 229-4ubuntu11), libnm-util2:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libappstream-glib8:amd64 (0.5.13-1ubuntu3, 0.5.13-1ubuntu4), gnome-calculator:amd64 (1:3.18.3-0ubuntu1, 1:3.18.3-0 ubuntu1.16.04.1), systemd-sysv:amd64 (229-4ubuntu10, 229-4ubuntu11), libpam-systemd:amd64 (229-4ubuntu10, 229-4ubuntu11), systemd:amd64 (229-4ubuntu10, 229-4ubuntu11), gir1.2-dbusmenu-glib-0.4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), libdbusmenu-gtk3-4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), lightdm:amd64 (1.18.2-0ubuntu2, 1.18.3-0ubuntu1), liblightdm-gobject-1-0:amd64 (1.18.2-0ubuntu2, 1.18.3-0ubuntu1) End-Date: 2016-10-13 09:01:06 After downloading version 1.2.2-0ubuntu0.16.04.1 copies of libnm-glib- vpn1:amd64 libnm-glib4:amd64 libnm-util2:amd64 libnm0:amd64 network- manager:amd64 and installing them via: sudo -H dpkg -i *.deb my name resolution started working again. Additional information: % lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 % apt-cache policy libnm-glib-vpn1 libnm-glib4 libnm-util2 libnm0 network-manager libnm-glib-vpn1: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm-glib4: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm-util2: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm0: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages network-manager: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages % apt-cache policy vpnc vpnc: Installed: 0.5.3r550-2build1
[Desktop-packages] [Bug 1629611] Re: dns server priority broken
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 This is not fixed, but is marked as a duplicate of #1624317 ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629276] Re: network-manager ignoring DNS settings in wifi connections
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629276 Title: network-manager ignoring DNS settings in wifi connections Status in network-manager package in Ubuntu: Confirmed Bug description: Since updating to network-manager 1.2.4-0ubuntu1 and libnss-resolve 231-7 on the 28th, yakkety is now ignoring manual DNS settings on wifi connections. The resolv.conf file is points to 127.0.1.1 instead of what is configured in the connection. To recreate --- On Ubuntu 16.10 (fully patched as of 2016-09-30): 1) Create an ipv4 wifi connection, with a manually set a dns server. 2) Connect to that wifi connection 3) Test name resolution - it will still be using 127.0.1.1 instead of your manually configured server This might be considered a security problem for people that use special DNS configurations or dnscrypt. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: network-manager 1.2.4-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-9136.55-generic 4.4.16 Uname: Linux 4.4.0-9136-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.3-0ubuntu7 Architecture: amd64 CurrentDesktop: Unity:Unity7 Date: Fri Sep 30 05:47:57 2016 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 192.168.9.240 dev wlp3s0 proto static metric 600 169.254.0.0/16 dev wlp3s0 scope link metric 1000 192.168.9.0/24 dev wlp3s0 proto kernel scope link src 192.168.9.153 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICETYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlp3s0wifi connected /org/freedesktop/NetworkManager/Devices/0 dusk f7b9d8b8-06b6-4d6a-850b-cfd4ebec44ab /org/freedesktop/NetworkManager/ActiveConnection/0 enp2s0f1 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- -- -- hfp/org/bluez/hci0/dev_4C_7C_5F_9E_A6_3C gsm unavailable /org/freedesktop/NetworkManager/Devices/3 -- -- -- loloopback unmanaged /org/freedesktop/NetworkManager/Devices/2 -- -- -- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.4connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629276/+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 1629611] Re: dns server priority broken
Seems to work in 1.4.4-1ubuntu3 in 17.04 at least... Thanks -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
That is certainly a possibility, but unfortunately returns us to a state where applications have to be restarted when nameservers change (glibc resolved.conf issue). That's probably even worse in my situation at least. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Unfortunately not much traction here, and this appears to annoy people across distros. In the meantime, an ugly hack is to manually add all internal domains to the NetworkManager VPN config file's dns-search= parameter: dns-search=domain1.lan;domain2.lan;domain3.lan;example.com; This causes NetworkManager to split DNS all lookups for these domains to the VPN DNS server, but with the added overhead of searching through all domains for non-existing hostname queries (make sure the primary internal domains are mentioned first). Also, for a multi-city setup like ours, I need to add A LOT of domains to get a functional DNS while on VPN - Including in-addr.arpa specifications for all IP subnets. So there's a way to sweeten the deal - but this is by no means anything other than a hack. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Wow - Long message, but what I got from it was "I need to see a debug log", correct? I'll attach that... I'll also point you to the problematic part: Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1915] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "workdom.lan" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1915] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "22.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "23.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "workdom.lan" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "22.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "23.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@enp0s31f6' Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1917] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@enp0s31f6' Now for this test, I'm using the same DNS before and after, but the VPN connection adds DNS resolution using the VPN provided DNS ONLY for the domains it feels is behind the VPN, and there's nothing I can seemingly do to change that behaviour. This is the exact assumption that breaks VPN for many users. When I connect to VPN, especially one that becomes my default gateway, I need all DNS requests to go the the DNS servers behind the VPN. Need more info, let me know. ** Attachment added: "network-manager.log" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+attachment/4787680/+files/network-manager.log -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Here's the thing, I'm on 16.10 which has the debian equiv listed as stretch/sid and my network-manager version is 1.2.4-0ubuntu1. Looking at Debian stretch and sid, they have network-manager packages in various versions but not 1.2.4. Furthermore, since Ubuntu employ their own patches, backports, versions, scripts, configuration etc, It'd be wrong of me to file this bug upstream, since I'd certainly risk wasting the Debian folks' time with something that might very well be Ubuntu specific. I simply cannot be certain. The only proper way to do this, would be for the Ubuntu maintainer to have a look at this bug and decide whether we're dealing with an Ubuntu specific config issue or something upstream and take the proper action upstream if needed. I have found similar but not identical reports in Debian, so I cannot reference anything that resembles duplicates. /T -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1629611] Re: dns server priority broken
I'll do it :) Any helpful pointers to which package/version i should reference, since I don't have the real debian version of this package anywhere? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1629611] Re: dns server priority broken
No, that does not seem like the problem to me - Or it's not described correctly. I can't seem to find a proper match in that list. resolv.conf is not the issue here - the problem is in the DNS servers that dnsmasq uses. I.e. one is added to dnsmasq when my wireless connection comes up, and when I launch my VPN, to more are APPENDED. And it seems like dnsmasq will try by wifi DNS first, VPN DNS later. So for split DNS, the VPN DNS servers are not queried at all, causing problems. The proper way is probably to PREPEND the VPN DNS servers to the list of DNS servers that dnsmasq uses or otherwise prioritize these over previously configured servers. That way everything should work as expected. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1592721] Re: Don't write search domains to resolv.conf in the case of split DNS
This bug seems to bite me in a slightly different way. Please let me know if you feel that this is really a separate bug... Also, this is happening on Yakkety - network-manager-1.2.4-0ubuntu1 When I connect to my work VPN, I'm not using split-tunnelling. Still the DNS resolution is split, causing DNS resolution to only be correct for my primary VPN search domain. This log snippet seems to explain it all: - 192.168.0.1 is my home ADSL DNS. - example.local is the search suffix provided by my VPN. - 10.10.10.12 and 10.10.10.13 are my VPN provided DNS servers. Oct 12 06:43:04 bar14860 NetworkManager[870]: [1476261784.8455] dns-mgr: Writing DNS information to /sbin/resolvconf Oct 12 06:43:04 bar14860 dnsmasq[1226]: setting upstream servers from DBus Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 192.168.0.1#53(via enp0s31f6) Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 NetworkManager[870]: [1476261784.9543] policy: set 'vpn0' (vpn0) as default for IPv4 routing and DNS The result of this is that all my other internal work-domains does not work at all, and may, as the bug describes, leak onto the internet as well. If you need more info, let me know. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1592721 Title: Don't write search domains to resolv.conf in the case of split DNS Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Released Bug description: [Impact] All VPN users meaning to use split-tunnelling in a situation where leaking DNS data to the internet about what might be behind their VPN is undesirable. [Test case] 1) connect to VPN 2) Use dig to request a name that should be on the VPN 3) Verify (kill -USR1 the dnsmasq binary from NM) that the request has only gone through the VPN nameservers (only its request number should have increased by one) 4) Use dig to request a name off-VPN, such as google.com. 5) Verify (kill -USR1 again) that the request has caused the non-VPN nameserver request number to increase, and that the VPN number has not increased. It is easier to verify this when there is as little traffic as possible on the system, to avoid spurious DNS requests which would make it harder to validate the counters. [Regression potential] This change modifies the way in which DNS nameservers and search domains are passed to dnsmasq, as such, if a VPN is configured in a non-standard way and intended to be used to resolve all network requests (which is typically not the case for split-tunnelling) or if the public network is intended to always resolve all requests while the VPN still provides search domains, one might observe incorrect behavior. Possible failure cases would include failure to resolve names correctly (resulting in NXDOMAIN or REFUSED from dnsmasq) or resolving to the incorrect values (if the wrong nameserver is used). --- Currently, NM will write all search domains to both any DNS-handling plugins running, and also to resolv.conf / resolvconf; in all cases. The issue is that doing so means that in the split-DNS case on VPNs, you might get a negative response from all nameservers, then a new request by glibc with the search tacked on, to nameservers again, which might cause DNS requests for "private" resources (say, on the VPN) to be sent to external, untrusted resolvers, or for DNS queries not meant for VPN nameservers to be sent through the VPN anyway. This is fixable in the case where we have a caching plugin running (such as dnsmasq). dnsmasq will already know about the search domains and use that to limit queries to the right nameservers when a VPN is running. Writing search domains to resolv.conf is unnecessary in this case. We should still write search domains if no caching gets done, as we then need to expect glibc to send requests as it otherwise would. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1592721/+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 1629611] [NEW] dns server priority broken
Public bug reported: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: New Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
You're absolutely right - Changed to systemd ** Package changed: transmission (Ubuntu) => systemd (Ubuntu) ** Changed in: systemd (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: New Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532552] Re: transmission-daemon settings gone after system halt
After this, I have no indication that anything should be wrong with transmission-daemon regarding this, so I'm closing the case. ** Changed in: transmission (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1532552 Title: transmission-daemon settings gone after system halt Status in transmission package in Ubuntu: Invalid Bug description: Ubuntu-15.10, amd64 systemd-225-1ubuntu9 transmission-daemon-2.84-1ubuntu1 I've noticed more than once, that "halt" can cause transmission-daemon to loose it's settings. AFAIK, "halt" is not that different from "poweroff" or "reboot" in regards to the shutdown sequence, so it is probably a problem for those as well. What I've noticed is that after my system comes back up after being halted, transmission-daemon won't start, citing config issues. Looking at /etc/transmission-daemon/settings.json, it's there but it's empty. This does not happen every time, but I've seen it on at least 3 different occasions. My guess (and I'm relatively new to systemd) is that while the transmission-daemon systemd unit-file wants to start after network.target, there is nothing that would prompt a "stop" of the service during shutdown. This seems to leave a race where the transmission-daemon is killed too close to remounting the / filesystem read-only, giving the daemon enough time to truncate it's config, yet making it impossible for the daemon to write it's settings, as it likes to do on "stop". My / filesystem is XFS, but that does not seem to have anything to do with this. I'm still looking for a way to map out the dependencies of systemd on shutdown, but it seems to me that perhaps adding Require=network.target to the unit-file might cause the daemon to stop early and solve this issue. Please let me know if you need anything else To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1532552/+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 1532552] Re: transmission-daemon settings gone after system halt
I was wrong. It appears as if the XFS filesystem on / is the actual culprit here. The way XFS works, makes it lose last-second changes such as the new settings file written by transmission-daemon, whet the power is cut after halt. I've added a "sync" to my UPS power-off script and everything appears to be much more stable now. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1532552 Title: transmission-daemon settings gone after system halt Status in transmission package in Ubuntu: Invalid Bug description: Ubuntu-15.10, amd64 systemd-225-1ubuntu9 transmission-daemon-2.84-1ubuntu1 I've noticed more than once, that "halt" can cause transmission-daemon to loose it's settings. AFAIK, "halt" is not that different from "poweroff" or "reboot" in regards to the shutdown sequence, so it is probably a problem for those as well. What I've noticed is that after my system comes back up after being halted, transmission-daemon won't start, citing config issues. Looking at /etc/transmission-daemon/settings.json, it's there but it's empty. This does not happen every time, but I've seen it on at least 3 different occasions. My guess (and I'm relatively new to systemd) is that while the transmission-daemon systemd unit-file wants to start after network.target, there is nothing that would prompt a "stop" of the service during shutdown. This seems to leave a race where the transmission-daemon is killed too close to remounting the / filesystem read-only, giving the daemon enough time to truncate it's config, yet making it impossible for the daemon to write it's settings, as it likes to do on "stop". My / filesystem is XFS, but that does not seem to have anything to do with this. I'm still looking for a way to map out the dependencies of systemd on shutdown, but it seems to me that perhaps adding Require=network.target to the unit-file might cause the daemon to stop early and solve this issue. Please let me know if you need anything else To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1532552/+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 1532552] [NEW] transmission-daemon settings gone after system halt
Public bug reported: Ubuntu-15.10, amd64 systemd-225-1ubuntu9 transmission-daemon-2.84-1ubuntu1 I've noticed more than once, that "halt" can cause transmission-daemon to loose it's settings. AFAIK, "halt" is not that different from "poweroff" or "reboot" in regards to the shutdown sequence, so it is probably a problem for those as well. What I've noticed is that after my system comes back up after being halted, transmission-daemon won't start, citing config issues. Looking at /etc/transmission-daemon/settings.json, it's there but it's empty. This does not happen every time, but I've seen it on at least 3 different occasions. My guess (and I'm relatively new to systemd) is that while the transmission-daemon systemd unit-file wants to start after network.target, there is nothing that would prompt a "stop" of the service during shutdown. This seems to leave a race where the transmission-daemon is killed too close to remounting the / filesystem read-only, giving the daemon enough time to truncate it's config, yet making it impossible for the daemon to write it's settings, as it likes to do on "stop". My / filesystem is XFS, but that does not seem to have anything to do with this. I'm still looking for a way to map out the dependencies of systemd on shutdown, but it seems to me that perhaps adding Require=network.target to the unit-file might cause the daemon to stop early and solve this issue. Please let me know if you need anything else ** Affects: transmission (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1532552 Title: transmission-daemon settings gone after system halt Status in transmission package in Ubuntu: New Bug description: Ubuntu-15.10, amd64 systemd-225-1ubuntu9 transmission-daemon-2.84-1ubuntu1 I've noticed more than once, that "halt" can cause transmission-daemon to loose it's settings. AFAIK, "halt" is not that different from "poweroff" or "reboot" in regards to the shutdown sequence, so it is probably a problem for those as well. What I've noticed is that after my system comes back up after being halted, transmission-daemon won't start, citing config issues. Looking at /etc/transmission-daemon/settings.json, it's there but it's empty. This does not happen every time, but I've seen it on at least 3 different occasions. My guess (and I'm relatively new to systemd) is that while the transmission-daemon systemd unit-file wants to start after network.target, there is nothing that would prompt a "stop" of the service during shutdown. This seems to leave a race where the transmission-daemon is killed too close to remounting the / filesystem read-only, giving the daemon enough time to truncate it's config, yet making it impossible for the daemon to write it's settings, as it likes to do on "stop". My / filesystem is XFS, but that does not seem to have anything to do with this. I'm still looking for a way to map out the dependencies of systemd on shutdown, but it seems to me that perhaps adding Require=network.target to the unit-file might cause the daemon to stop early and solve this issue. Please let me know if you need anything else To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1532552/+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 1532553] [NEW] /etc/halt.local has become /usr/sbin/halt.local
Public bug reported: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas ** Affects: transmission (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in transmission package in Ubuntu: New Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1532553/+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 1057833] Re: soffice.bin crashed with SIGSEGV in Menu::~Menu()
** Visibility changed to: Public -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1057833 Title: soffice.bin crashed with SIGSEGV in Menu::~Menu() Status in “libreoffice” package in Ubuntu: New Bug description: Browsing templates (previewing) produced this crash ProblemType: Crash DistroRelease: Ubuntu 12.10 Package: libreoffice-core 1:3.6.1~rc2-1ubuntu5 ProcVersionSignature: Ubuntu 3.5.0-15.23-generic 3.5.4 Uname: Linux 3.5.0-15-generic x86_64 ApportVersion: 2.5.2-0ubuntu4 Architecture: amd64 CrashCounter: 1 Date: Thu Sep 27 21:55:45 2012 ExecutablePath: /usr/lib/libreoffice/program/soffice.bin InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release amd64 (20120425) ProcCmdline: /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=6 ProcEnviron: PATH=(custom, user) LANG=en_DK.UTF-8 SHELL=/bin/bash SegvAnalysis: Segfault happened at: 0x7f122c1053eb:mov(%rdi),%rax PC (0x7f122c1053eb) ok source (%rdi) (0x) not located in a known VMA region (needed readable region)! destination %rax ok SegvReason: reading NULL VMA Signal: 11 SourcePackage: libreoffice StacktraceTop: ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so Menu::~Menu() () from /usr/lib/libreoffice/program/libvcllo.so MenuBar::~MenuBar() () from /usr/lib/libreoffice/program/libvcllo.so VCLXMenu::~VCLXMenu() () from /usr/lib/libreoffice/program/libtklo.so Title: soffice.bin crashed with SIGSEGV in Menu::~Menu() UpgradeStatus: Upgraded to quantal on 2012-08-16 (42 days ago) UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo wireshark XsessionErrors: (gnome-settings-daemon:2720): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed (gnome-settings-daemon:2720): libappindicator-CRITICAL **: app_indicator_set_label: assertion `IS_APP_INDICATOR (self)' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1057833/+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 1046822] [NEW] Zooming does not work corrently
Public bug reported: In gnome-terminal CTRL-'+' and CTRL-'-' is supposed to zoom in and out respectively: Zoom in should: increase the font size and resize the window to match the new font size (keep rows and cols consistent) Zoom out should do the exact opposite: reduce the font size and resize the window to match the new font size (keep rows and cols consistent) This does not work within unity. Instead, it would appear that the font size is handled correctly, whereas the windows resizing is messed up. Consequently, repeating a few zoom ins and outs will result in an unusably small window - but with the font size corect. Note: It works, runing under gnome-shell ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1046822 Title: Zooming does not work corrently Status in “gnome-terminal” package in Ubuntu: New Bug description: In gnome-terminal CTRL-'+' and CTRL-'-' is supposed to zoom in and out respectively: Zoom in should: increase the font size and resize the window to match the new font size (keep rows and cols consistent) Zoom out should do the exact opposite: reduce the font size and resize the window to match the new font size (keep rows and cols consistent) This does not work within unity. Instead, it would appear that the font size is handled correctly, whereas the windows resizing is messed up. Consequently, repeating a few zoom ins and outs will result in an unusably small window - but with the font size corect. Note: It works, runing under gnome-shell To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1046822/+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 1046822] Re: Zooming does not work corrently
This is on quantal (up to date as per now) - Problem existed on precise last I checked too. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1046822 Title: Zooming does not work corrently Status in “gnome-terminal” package in Ubuntu: New Bug description: In gnome-terminal CTRL-'+' and CTRL-'-' is supposed to zoom in and out respectively: Zoom in should: increase the font size and resize the window to match the new font size (keep rows and cols consistent) Zoom out should do the exact opposite: reduce the font size and resize the window to match the new font size (keep rows and cols consistent) This does not work within unity. Instead, it would appear that the font size is handled correctly, whereas the windows resizing is messed up. Consequently, repeating a few zoom ins and outs will result in an unusably small window - but with the font size corect. Note: It works, runing under gnome-shell To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1046822/+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 951246] Re: 13b1:002f Linksys AE1000 v1 802.11n [Ralink RT3572] not usable in network manager or elsewhere
Not a firefox bug but a missing driver AFAICT -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/951246 Title: 13b1:002f Linksys AE1000 v1 802.11n [Ralink RT3572] not usable in network manager or elsewhere Status in “firefox” package in Ubuntu: Confirmed Bug description: USB wireless worked at one time in Ubuntu. No longer works and does not show a module loaded or does it work. Device shows in lsusb but nowhere else. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: firefox 11.0~b7+build1-0ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9 Uname: Linux 3.2.0-18-generic x86_64 NonfreeKernelModules: nvidia AddonCompatCheckDisabled: False AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24. ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: ron1770 F pulseaudio /dev/snd/controlC0: ron1770 F pulseaudio /dev/snd/pcmC0D0p: ron1770 F...m pulseaudio BuildID: 20120309125033 CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xfb12 irq 43' Mixer name : 'Realtek ALC888' Components : 'HDA:10ec0888,80860037,00100202' Controls : 43 Simple ctrls : 22 Card1.Amixer.info: Card hw:1 'NVidia'/'HDA NVidia at 0xfb08 irq 17' Mixer name : 'Nvidia GPU 0d HDMI/DP' Components : 'HDA:10de000d,10de0101,00100100' Controls : 24 Simple ctrls : 4 Channel: beta CurrentDmesg: [ 136.353372] e1000e: eth0 NIC Link is Down [ 227.240075] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx [ 227.240082] e1000e :00:19.0: eth0: 10/100 speed: disabling TSO Date: Fri Mar 9 19:06:03 2012 ForcedLayersAccel: False IfupdownConfig: auto lo iface lo inet loopback InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Beta amd64 (20120301) IpRoute: default via 192.168.1.1 dev eth0 proto static 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.145 metric 1 IwConfig: lono wireless extensions. eth0 no wireless extensions. Prefs: browser.startup.homepage_override.buildID - 20120309125033 browser.places.smartBookmarksVersion - 2 extensions.lastAppVersion - 11.0 browser.startup.homepage_override.mstone - rv:11.0 places.history.expiration.transient_current_max_pages - 104858 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash Profiles: Profile0 (Default) - LastVersion=11.0/20120309125033 (Running) RfKill: RunningIncompatibleAddons: False SourcePackage: firefox UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/22/2011 dmi.bios.vendor: Intel Corp. dmi.bios.version: TCIBX10H.86A.0046.2011.0422.1617 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: DH55HC dmi.board.vendor: Intel Corporation dmi.board.version: AAE70933-505 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrTCIBX10H.86A.0046.2011.0422.1617:bd04/22/2011:svn:pn:pvr:rvnIntelCorporation:rnDH55HC:rvrAAE70933-505:cvn:ct3:cvr: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/951246/+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 510059] Re: Gvfs keeps asking for password when trying to mount Samba share
I have this exact problem on a freshly installed Precise. This is what I had to do, to fix the problem: in /etc/samba/smb.conf add the following to the bottom of the [global] section: client lanman auth = yes client ntlmv2 auth = no I could gvfs-mount a Windows 2008 share, but not an Alfresco CIFS share. With the above changes to smb.conf, I can access all shares withoput problems. I didn't have this problem on a freshly installed Oneiric machine, so I'm not sure what's changed og wether thes should be fixed in gvfs or in the default samba installation. -- 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/510059 Title: Gvfs keeps asking for password when trying to mount Samba share Status in GVFS: New Status in “gvfs” package in Ubuntu: Triaged Bug description: Binary package hint: nautilus My Ubuntu Desktop (9.10, 64-bit) VM can't connect to my Windows 7 (64-bit, Ultimate) File Share using Nautilus. I enter smb://comuterName in the address bar and then it comes up with a password dialog (see screenshot) and then after entering the correct login info, the dialog disappears for a second or two but then reappears again. The dialog always comes back up and the share is never mounted. * Connecting from an XP box on the network to the windows 7 share works just fine. * Connecting from the Ubuntu machine to the windows 7 share using the appropriate 'smbmount' command works just fine. * Connecting from the Ubuntu machine (using the nautilus GUI) to the XP box (password protected) works just fine. * Then I turned off password protection in Win7, rebooted the win7 machine, and still all of the above tests turned out the same. And the Ubuntu machine still doesn't connect to the windows share using the nautilus GUI, and still displays the password dialog even though no password is required anymore. * I tried using smbclient to view the shares, here is the output (not sure if I should be trying something else using the smbclient program): o eddie@eddie-ubuntu:~$ smbclient -L eddie-win7 Enter eddie's password: session setup failed: SUCCESS - 0 ProblemType: Bug Architecture: amd64 Date: Sun Jan 17 15:41:28 2010 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/nautilus InstallationMedia: Ubuntu 9.10 Karmic Koala - Release amd64 (20091027) Package: nautilus 1:2.28.1-0ubuntu3 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-server SourcePackage: nautilus Uname: Linux 2.6.31-17-server x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/510059/+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 861265] Re: [Oneiric] [Regression] firefox title bar does not appear (same problem with thunderbird) no window decoration for either application.
In my case, I seem to loose the windows controls some times. Some times
they are there... My feeling is, it usually has something to do with
leaving fullscreen mode...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/861265
Title:
[Oneiric] [Regression] firefox title bar does not appear (same problem
with thunderbird) no window decoration for either application.
Status in “firefox” package in Ubuntu:
Confirmed
Bug description:
Following the latest round of updates (as of 28/10/2011) when either
thunderbird or firefox start they have no window decoration.
Screenshot attached.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: firefox 7.0+build2+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-12.19-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
ArecordDevices:
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: dave 1873 F pulseaudio
BuildID: 20110926064452
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xfc02 irq 48'
Mixer name : 'Conexant CX20561 (Hermosa)'
Components : 'HDA:14f15051,17aa2100,0010'
Controls : 16
Simple ctrls : 8
Card29.Amixer.info:
Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw
7VHT12WW-1.01'
Mixer name : 'ThinkPad EC 7VHT12WW-1.01'
Components : ''
Controls : 1
Simple ctrls : 1
Card29.Amixer.values:
Simple mixer control 'Console',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Channel: release
Date: Wed Sep 28 10:14:48 2011
EcryptfsInUse: Yes
ForcedLayersAccel: False
IfupdownConfig:
auto lo
iface lo inet loopback
IncompatibleExtensions: LastPass - ID=supp...@lastpass.com, Version=1.75.0,
minVersion=1.9a2, maxVersion=1.9.6, Location=app-profile, Type=extension,
Active=Yes
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Alpha amd64 (20110803.1)
IpRoute:
default via 192.168.100.1 dev eth1 proto static
169.254.0.0/16 dev eth1 scope link metric 1000
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.206
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=7.0/20110926064452 (Running)
RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: Upgraded to oneiric on 2011-09-22 (5 days ago)
dmi.bios.date: 04/22/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6FET66WW (2.16 )
dmi.board.name: 2241B48
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias:
dmi:bvnLENOVO:bvr6FET66WW(2.16):bd04/22/2009:svnLENOVO:pn2241B48:pvrThinkPadT500:rvnLENOVO:rn2241B48:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2241B48
dmi.product.version: ThinkPad T500
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/861265/+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
