[Desktop-packages] [Bug 2052624] Re: Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds
I've just tested the latest snap from the beta channel (2751). I deleted ~/.chromium-browser.init, and I can confirm that the webcam works fine now in the default configuration. VAAPI is also still functional according to intel_gpu_top. Thanks! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2052624 Title: Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds Status in chromium-browser package in Ubuntu: Fix Released Bug description: Looking at https://discourse.ubuntu.com/t/an-overview-of-hardware- acceleration-in-chromium/36672, a couple of flags are added for beta and edge channel builds of Chromium to enable VAAPI. You may want to remove the flag --video-capture-use-gpu-memory-buffer from the builds, as it completely breaks webcam input: ERROR:video_capture_impl.cc(501)] Failed to open GpuMemoryBuffer handle It can be worked around by creating ~/.chromium-browser.init and adding CHROMIUM_FLAGS="--disable-video-capture-use-gpu-memory-buffer" to it, but that is not exactly user friendly (and rather redundant). Upstream the Chromium developers say that the --video-capture-use-gpu- memory-buffer flag is broken and that packagers should no longer be using it. https://issues.chromium.org/issues/40279468 >> Do the packagers need to be advised to remove this, or should the flags work as intended? > Yes. If you could inform them, please do so. On Chrome M116 that flag got broken, unfortunately. The flag had absolutely no effect before that, actually. In the future it will be enabled automatically when supported. So it's a good idea to remove that flag from the config for all versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2052624/+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 2052624] Re: Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds
Sure, no problem. Could you by any chance do a new build for the beta channel with this fix included? Then I can test if the webcam still works in the default configuration, without the ~/.chromium-browser.init file. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2052624 Title: Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds Status in chromium-browser package in Ubuntu: Fix Committed Bug description: Looking at https://discourse.ubuntu.com/t/an-overview-of-hardware- acceleration-in-chromium/36672, a couple of flags are added for beta and edge channel builds of Chromium to enable VAAPI. You may want to remove the flag --video-capture-use-gpu-memory-buffer from the builds, as it completely breaks webcam input: ERROR:video_capture_impl.cc(501)] Failed to open GpuMemoryBuffer handle It can be worked around by creating ~/.chromium-browser.init and adding CHROMIUM_FLAGS="--disable-video-capture-use-gpu-memory-buffer" to it, but that is not exactly user friendly (and rather redundant). Upstream the Chromium developers say that the --video-capture-use-gpu- memory-buffer flag is broken and that packagers should no longer be using it. https://issues.chromium.org/issues/40279468 >> Do the packagers need to be advised to remove this, or should the flags work as intended? > Yes. If you could inform them, please do so. On Chrome M116 that flag got broken, unfortunately. The flag had absolutely no effect before that, actually. In the future it will be enabled automatically when supported. So it's a good idea to remove that flag from the config for all versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2052624/+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 2052624] [NEW] Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds
Public bug reported: Looking at https://discourse.ubuntu.com/t/an-overview-of-hardware- acceleration-in-chromium/36672, a couple of flags are added for beta and edge channel builds of Chromium to enable VAAPI. You may want to remove the flag --video-capture-use-gpu-memory-buffer from the builds, as it completely breaks webcam input: ERROR:video_capture_impl.cc(501)] Failed to open GpuMemoryBuffer handle It can be worked around by creating ~/.chromium-browser.init and adding CHROMIUM_FLAGS="--disable-video-capture-use-gpu-memory-buffer" to it, but that is not exactly user friendly (and rather redundant). Upstream the Chromium developers say that the --video-capture-use-gpu- memory-buffer flag is broken and that packagers should no longer be using it. https://issues.chromium.org/issues/40279468 >> Do the packagers need to be advised to remove this, or should the flags work as intended? > Yes. If you could inform them, please do so. On Chrome M116 that flag got broken, unfortunately. The flag had absolutely no effect before that, actually. In the future it will be enabled automatically when supported. So it's a good idea to remove that flag from the config for all versions. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New ** Description changed: Looking at https://discourse.ubuntu.com/t/an-overview-of-hardware- acceleration-in-chromium/36672, a couple of flags are added for beta and edge channel builds of Chromium to enable VAAPI. - You may want to remove the flag `--video-capture-use-gpu-memory-buffer` + You may want to remove the flag --video-capture-use-gpu-memory-buffer from the builds, as it completely breaks webcam input: ERROR:video_capture_impl.cc(501)] Failed to open GpuMemoryBuffer handle It can be worked around by creating ~/.chromium-browser.init and adding CHROMIUM_FLAGS="--disable-video-capture-use-gpu-memory-buffer" to it, but that is not exactly user friendly (and rather redundant). Upstream the Chromium developers say that the --video-capture-use-gpu- memory-buffer flag is broken and that packagers should no longer be using it. https://issues.chromium.org/issues/40279468 >> Do the packagers need to be advised to remove this, or should the flags work as intended? > Yes. If you could inform them, please do so. On Chrome M116 that flag got broken, unfortunately. The flag had absolutely no effect before that, actually. In the future it will be enabled automatically when supported. So it's a good idea to remove that flag from the config for all versions. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2052624 Title: Stop using --video-capture-use-gpu-memory-buffer flag in beta/edge builds Status in chromium-browser package in Ubuntu: New Bug description: Looking at https://discourse.ubuntu.com/t/an-overview-of-hardware- acceleration-in-chromium/36672, a couple of flags are added for beta and edge channel builds of Chromium to enable VAAPI. You may want to remove the flag --video-capture-use-gpu-memory-buffer from the builds, as it completely breaks webcam input: ERROR:video_capture_impl.cc(501)] Failed to open GpuMemoryBuffer handle It can be worked around by creating ~/.chromium-browser.init and adding CHROMIUM_FLAGS="--disable-video-capture-use-gpu-memory-buffer" to it, but that is not exactly user friendly (and rather redundant). Upstream the Chromium developers say that the --video-capture-use-gpu- memory-buffer flag is broken and that packagers should no longer be using it. https://issues.chromium.org/issues/40279468 >> Do the packagers need to be advised to remove this, or should the flags work as intended? > Yes. If you could inform them, please do so. On Chrome M116 that flag got broken, unfortunately. The flag had absolutely no effect before that, actually. In the future it will be enabled automatically when supported. So it's a good idea to remove that flag from the config for all versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2052624/+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 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
It's fixed upstream as well now: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/6920b6ceb1c2e7856ad76e118ee5b4dd36130735 -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Committed Bug description: * Impact The recent SRU created a regression in IPv6 routing order * Test Case 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. * Regression potential The patch change the IPv6 addresses order to match the behaviour from the previous version. If that was buggy the routing order would still be wrong, so we should check that IPv6 setups behave as expected. --- Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
kevin@arcadia:~$ apt info network-manager Package: network-manager Version: 1.36.6-0ubuntu2 kevin@arcadia:~$ apt info libnm0 Package: libnm0 Version: 1.36.6-0ubuntu2 I have installed network-manager and libnm0 version 1.36.6-0ubuntu2 from jammy-proposed. After connecting to a network with both SLAAC and DHCPv6 enabled, the DHCPv6 address was selected as the source address again, like it was in version 1.36.4, prior to the update introducing this bug. This restores the original and desired behaviour. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Committed Bug description: * Impact The recent SRU created a regression in IPv6 routing order * Test Case 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. * Regression potential The patch change the IPv6 addresses order to match the behaviour from the previous version. If that was buggy the routing order would still be wrong, so we should check that IPv6 setups behave as expected. --- Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
This seems to restore previous behaviour yes. -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: In Progress Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS It looks like Ubuntu just introduced that bug by
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
Unfortunately I was not tracking jammy-proposed, so I only found out about this bug when it entered jammy-updates. I don't think my configuration is that exotic to be honest. Many companies use DHCPv6 servers giving out static leases, and many companies use firewalls to restrict incoming (SSH) connections to their servers. And not many network administrators disable SLAAC as that would break IPv6 for all Android users. So corporate and home networks with DHCPv6 and SLAAC enabled are quite common. How viable would it be to create something like 1.36.7~really1.36.4 or something like that, which would be the previous version with only commit 6a82dd18 cherry picked to fix the hotspot issue and not introduce the source address selection bug? I suppose upstream would at some point release 1.36.9, which will hopefully have this bug fixed, and also have commit 6a82dd18 included, so Ubuntu can go back to the upstream version then. -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Triaged Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android).
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
@seb128 What is the plan for the network-manager package in Ubuntu jammy-updates? Is it to be left broken until upstream fixes this bug? Because I think that the problem this last version introduces is a lot bigger than the problem(s) it solves. Therefore I would say that it can be defended to upload a new version that restores 1.36.4-2ubuntu1 for the time being, and then re-sync with upstream when (or if) this bug is fixed. As far as I'm aware, the update from 1.36.4 to 1.36.6 did not close any outstanding Launchpad bugs, so it didn't fix anything from Ubuntu's perspective. It just introduced this regression. -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in NetworkManager: New Status in network-manager package in Ubuntu: Triaged Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
** Summary changed: - NetworkManager 1.36.6 orders IPv6 addresses incorrectly + NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC -- 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/1977619 Title: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC Status in network-manager package in Ubuntu: Confirmed Bug description: Situation: My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release, any of them (or a combination) introducing this bug: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC/autoconf last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match.
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: Situation: - My network has both DHCPv6 and SLAAC for IPv6. From a privacy + My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Constantly removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router are now the only ways to stop NetworkManager from preferring SLAAC over DHCPv6. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working: the SLAAC address should never be used as the preferred address if a DHCPv6 lease is given. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, - those should take first priority, with DHCPv6 second and SLAAC last. + those should take first priority, with DHCPv6 second and SLAAC/autoconf + last. Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. Note that "just disabling SLAAC RA's on the router" is not something everybody can do, as it requires root access to the device. Moreover, it would break IPv6 connectivity entirely for devices that don't support DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS It looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. System information: /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: Situation: My network has both DHCPv6 and SLAAC for IPv6. From a privacy perspective, for readability reasons and for network management policies, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724, the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. - Regression: Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS - Steps to reproduce: 1. Connect to a network where the router sends "A" and "M" bits in the RA's and has a DHCPv6 server running (e.g. any OpenWrt router). 2. When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not the case. (The Linux kernel uses the address highest in the list as preferred.) 3. When running something like `curl ifconfig.co`, the SLAAC address is being returned, which makes sense as that is now preferred by the kernel. (But it shouldn't be.) - Desired behaviour: NetworkManager should always sort DHCPv6 addresses above SLAAC addresses, as is the case for all versions prior to 1.36.6 and also corrected again in 1.38.0. In case static addresses are manually set, those should take first priority, with DHCPv6 second and SLAAC last. - Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on and cannot centrally configure), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. + Note that "just disabling SLAAC RA's on the router" is not something + everybody can do, as it requires root access to the device. Moreover, it + would break IPv6 connectivity entirely for devices that don't support + DHCPv6 (read: Android). Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. As that version is also used in Ubuntu kinetic, most likely this bug is not present there. Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. - System information: /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/;
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: - My network has both DHCPv6 and SLAAC for IPv6. From both a privacy - perspective and readability reasons, DHCPv6 should *always* be preferred - over SLAAC addresses when available. And according to RFC 6724 the - smaller /128 scope of the DHCPv6 address should be chosen over the - larger /64 scope of the SLAAC address. + Situation: + + My network has both DHCPv6 and SLAAC for IPv6. From a privacy + perspective, for readability reasons and for network management + policies, DHCPv6 should *always* be preferred over SLAAC addresses when + available. And according to RFC 6724, the smaller /128 scope of the + DHCPv6 address should be chosen over the larger /64 scope of the SLAAC + address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. + + Regression: + Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's - altogether is the only way to stop NetworkManager from preferring SLAAC - over DHCPv6 now. + on the router is the only way to stop NetworkManager from preferring + SLAAC over DHCPv6 now. None of the local options in NetworkManager + 1.36.6 are able to restore the previous, desired and correct way of + working. - Looking at the changelog of NetworkManager 1.36.6, things regarding IP - address order and temporary addresses have been changed in that release: + Looking at the changelog of NetworkManager 1.36.6, multiple things + regarding IP address order and temporary addresses have been changed in + that release: * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. * Ensure temporary IPv6 addresses are removed on disconnect and reapply. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS - When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 - addresses. With NetworkManager 1.36.4 this was not the case. (The Linux - kernel uses the address highest in the list as preferred.) + + Steps to reproduce: + + 1. Connect to a network where the router sends "A" and "M" bits in the + RA's and has a DHCPv6 server running (e.g. any OpenWrt router). + + 2. When running `ip -6 a`, the list now sorts SLAAC addresses above + DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not + the case. (The Linux kernel uses the address highest in the list as + preferred.) + + 3. When running something like `curl ifconfig.co`, the SLAAC address is + being returned, which makes sense as that is now preferred by the + kernel. (But it shouldn't be.) + + + Desired behaviour: + + NetworkManager should always sort DHCPv6 addresses above SLAAC + addresses, as is the case for all versions prior to 1.36.6 and also + corrected again in 1.38.0. In case static addresses are manually set, + those should take first priority, with DHCPv6 second and SLAAC last. + + + Implications: This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC - address that I have no influence on), I am being locked out of the - servers in question unless I forcefully remove the addresses or disable - SLAAC on my router, so my outgoing traffic is being routed through the - DHCPv6 address again. + address that I have no influence on and cannot centrally configure), I + am being locked out of the servers in question unless I forcefully + remove the addresses or disable SLAAC on my router, so my outgoing + traffic is being routed through the DHCPv6 address again. + + + Conclusion: So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it - should. + should. As that version is also used in Ubuntu kinetic, most likely this + bug is not present there. + + Looking at the changelog of 1.38.0: + + * Fix bug setting priority for IP addresses. + *
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: + + * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order. + * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set. + * Ensure temporary IPv6 addresses are removed on disconnect and reapply. + https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. More background here: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1974428/comments/11 -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection (in nm-connection-editor *not* selecting "Prefer temporary address" for IPv6 privacy extensions). Then it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred - over SLAAC addresses when available. + over SLAAC addresses when available. And according to RFC 6724 the + smaller /128 scope of the DHCPv6 address should be chosen over the + larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection. Then it would not generate temporary - addresses and use the DHCPv6 address as the source for outgoing traffic. + ip6.privacy=0 for the connection (in nm-connection-editor called "Prefer + temporary address"). Then it would use the DHCPv6 address as the source + for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. More background here: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1974428/comments/11 ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. And according to RFC 6724 the smaller /128 scope of the DHCPv6 address should be chosen over the larger /64 scope of the SLAAC address. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection (in nm-connection-editor called "Prefer - temporary address"). Then it would use the DHCPv6 address as the source - for all outgoing traffic. + ip6.privacy=0 for the connection (in nm-connection-editor *not* + selecting "Prefer temporary address" for IPv6 privacy extensions). Then + it would use the DHCPv6 address as the source for all outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 + + Looking at the changelog of 1.38.0: + + * Fix bug setting priority for IP addresses. + * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. + + https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS + + So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. + Please either backport the fix from 1.38.0 or revert to 1.36.4, which + was working fine. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Tags added: regression-update -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport the fix from 1.38.0 or revert to 1.36.4, which was working fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting - ip6.privacy=0 for the connection. + ip6.privacy=0 for the connection. Then it would not generate temporary + addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 - address would be used to connect to the outside world. + address would be used to connect to the outside world and be echoed + back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. Then it would not generate temporary addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world and be echoed back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic
[Desktop-packages] [Bug 1974428] Re: Update to the current 1.36 stable version
@seb128 I have created a new bug report with links to the upstream commits. The core of the issue is that IPv6 addresses are now being added in the wrong order, so the kernel prefers SLAAC addresses over DHCPv6 addresses, which should be the other way around. As this is a breaking change in source-based IPv6 routing in an LTS release, I think the impact is severe. In my opinion, this update should never have reached stable, especially because this bug is known upstream and fixed in a later version. I'm already quite stressed how this will turn out at work after the weekend. We use source-based ACL's on all of our firewalls, giving static DHCPv6 leases to our client devices. Now all of a sudden those addresses are no longer being used for outgoing traffic, but instead the non-controllable SLAAC-addresses are. This will lock everyone out of all servers. The only way to get the proper addresses to be preferred again seems to be to disable SLAAC on the router, because any local setting in NetworkManager no longer works. I can disable SLAAC without issues at home, because everything is 100% Ubuntu and Debian there. But in environments with other OS'es that don't support DHCPv6 (like Android), disabling SLAAC will break IPv6 on all such devices. Moreover, not everybody controls their own routers, so this really isn't much of a solution. Other options would be to downgrade and apt-mark hold network-manager on all Ubuntu 22.04 devices, or to completely change server firewall infrastructure by whitelisting prefixes. As you can see, none of these options sound appealing. So regarding the regression potential: it has severely regressed IPv6 handling, and definitely *not* fixed things. -- 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/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+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 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. - So this update introduces a very breaking change to an LTS release, - while LTS releases should be stable. + So this update introduces a very breaking change in IPv6 source address + selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. + So this update introduces a very breaking change to an LTS release, + while LTS releases should be stable. + I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change to an LTS release, while LTS releases should be stable. I should note that the bug is not
[Desktop-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting - net.ipv6.conf.all.use_tempaddr = 0 and - net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer - has any effect. + net.ipv6.conf.all.use_tempaddr=0 and + net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has + any effect. - Removing the SLAAC addresses with `ip addr del` or disabling RA's + Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- 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/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManager 1.38.0 on
[Desktop-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Tags added: jammy ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 - addresses. With NetworkManager 1.36.4 this was not the case. - - Unfortunately, this introduced this bug, which is really breaking a lot - of my use cases. + addresses. With NetworkManager 1.36.4 this was not the case. (The Linux + kernel uses the top address as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux - kernel uses the top address as preferred.) + kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. + + /etc/os-release: + + PRETTY_NAME="Ubuntu 22.04 LTS" + NAME="Ubuntu" + VERSION_ID="22.04" + VERSION="22.04 LTS (Jammy Jellyfish)" + VERSION_CODENAME=jammy + ID=ubuntu + ID_LIKE=debian +
[Desktop-packages] [Bug 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
I guess these commits are relevant: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/c631aa48f034ade2b5cb97ccc4462d56d80174e7 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/257221d1986b56cbb2e329fcc74a2daca145b7aa Bottom line: addresses are now being added in the wrong order, which is known and fixed upstream for 1.38.x, but never fixed for 1.36.x. -- 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
Comparing the output of `ip -6 a`, you can see that the dynamic addresses are no longer at the top of the list, where they should be. Before (network-manager 1.36.4): 2: eno0: mtu 1500 state UP qlen 1000 inet6 2a10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43194sec inet6 fd10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43194sec inet6 fd10:3781::0:9875:4dec:b9f9:e768/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781::0:f802:2428:9af1:dcb3/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute valid_lft forever preferred_lft forever After (network-manager 1.36.6): 2: eno0: mtu 1500 state UP qlen 1000 inet6 fd10:3781::0:9875:4dec:b9f9:e768/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781::0:f802:2428:9af1:dcb3/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 2a10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43194sec preferred_lft 43194sec inet6 fd10:3781:::bd0/128 scope global dynamic noprefixroute valid_lft 43194sec preferred_lft 43194sec inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute valid_lft forever preferred_lft forever On another machine with Debian sid and network-manager 1.38.0, it looks like the way it should be again (dynamic addresses at the top of the list, preferred to autoconfigured / temporary addresses): 2: wlan0: mtu 1500 state UP qlen 1000 inet6 fd10:3781:::5bf/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43193sec inet6 2a10:3781:::5bf/128 scope global dynamic noprefixroute valid_lft 43193sec preferred_lft 43193sec inet6 2a10:3781::0:42cd:4f1b:89b8:77fd/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fd10:3781::0:8a59:df52:9ea1:e7c8/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::a738:71dc:f10e:924e/64 scope link noprefixroute valid_lft forever preferred_lft forever So this bug was not present in NetworkManager 1.36.4, introduced in 1.36.6, and then fixed in 1.38.0. -- 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's - altogether is the only way to stop NetworkManager from prefering SLAAC + altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
Looking at the changelog of 1.38.0: * Fix bug setting priority for IP addresses. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. Please either backport it from 1.38.0 or revert to 1.36.4. ** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. - Physically removing the SLAAC addresses or disabling RA's altogether is - the only way to stop NetworkManager from prefering SLAAC over DHCPv6 - now. + Removing the SLAAC addresses with `ip addr del` or disabling RA's + altogether is the only way to stop NetworkManager from prefering SLAAC + over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1974428] Re: Update to the current 1.36 stable version
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619 -- 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/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+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 1977619] Re: DHCPv6 addresses are no longer preferred over SLAAC addresses
** Description changed: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS + When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 + addresses. With NetworkManager 1.36.4 this was not the case. + Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. -- 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1977619] [NEW] DHCPv6 addresses are no longer preferred over SLAAC addresses
Public bug reported: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. ** 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/1977619 Title: DHCPv6 addresses are no longer preferred over SLAAC addresses Status in network-manager package in Ubuntu: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr = 0 and net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer has any effect. Physically removing the SLAAC addresses or disabling RA's altogether is the only way to stop NetworkManager from prefering SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS Unfortunately, this introduced this bug, which is really breaking a lot of my use cases. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+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 1974428] Re: Update to the current 1.36 stable version
All of a sudden SLAAC addresses are preferred over DHCPv6 addresses, which should not be happening. Setting ip6.privacy=0 no longer helps, nor does setting net.ipv6.conf.all.use_tempaddr = 0 with sysctl. -- 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/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+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 1969243] [NEW] gdm 42.0-1ubuntu4 no longer shows Wayland option
Public bug reported: After updating gdm3 from 42.0-1ubuntu2 to 42.0-1ubuntu4 in jammy, it no longer shows any sessions in the bottom-right corner. When I log in, I am dropped into an X11 session, with no way to switch to Wayland. Downgrading the gdm3, gir1.2-gdm-1.0 and libgdm1 packages to 42.0-1ubuntu2 or 42.0-1ubuntu3 restores the option to select sessions and defaults to Wayland again. Looking at the changelog: gdm3 (42.0-1ubuntu4) jammy; urgency=medium * Drop patch disabling Wayland on hybrid laptops using Nvidia's drivers. It's not needed for Ubuntu 22.04 LTS (LP: #1968809) -- Jeremy Bicha Thu, 14 Apr 2022 14:29:35 -0400 However, all my machines are i915-only. ** Affects: gdm3 (Ubuntu) Importance: Undecided Status: New ** Tags: jammy -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gdm3 in Ubuntu. https://bugs.launchpad.net/bugs/1969243 Title: gdm 42.0-1ubuntu4 no longer shows Wayland option Status in gdm3 package in Ubuntu: New Bug description: After updating gdm3 from 42.0-1ubuntu2 to 42.0-1ubuntu4 in jammy, it no longer shows any sessions in the bottom-right corner. When I log in, I am dropped into an X11 session, with no way to switch to Wayland. Downgrading the gdm3, gir1.2-gdm-1.0 and libgdm1 packages to 42.0-1ubuntu2 or 42.0-1ubuntu3 restores the option to select sessions and defaults to Wayland again. Looking at the changelog: gdm3 (42.0-1ubuntu4) jammy; urgency=medium * Drop patch disabling Wayland on hybrid laptops using Nvidia's drivers. It's not needed for Ubuntu 22.04 LTS (LP: #1968809) -- Jeremy Bicha Thu, 14 Apr 2022 14:29:35 -0400 However, all my machines are i915-only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1969243/+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
Copy/paste works for me, but drag/drop does not. I can't even rearrange tabs or bookmarks. -- 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 1953685] Re: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?)
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1745098 Likely caused by this change: https://bugzilla.mozilla.org/show_bug.cgi?id=1737068 ** Bug watch added: Mozilla Bugzilla #1745098 https://bugzilla.mozilla.org/show_bug.cgi?id=1745098 ** Bug watch added: Mozilla Bugzilla #1737068 https://bugzilla.mozilla.org/show_bug.cgi?id=1737068 -- 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/1953685 Title: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?) Status in firefox package in Ubuntu: New Bug description: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since the update to Firefox 95, it's been very laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1953685/+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 1953685] Re: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?)
** Description changed: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since - the update to Firefox 95, it's been verry laggy; especially noticeable + the update to Firefox 95, it's been very laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. - - tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. + tl;dr: On old Intel graphics Firefox 94 was working well with GLX and + EGL, while EGL seems broken on Firefox 95. -- 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/1953685 Title: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?) Status in firefox package in Ubuntu: New Bug description: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since the update to Firefox 95, it's been very laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1953685/+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 1953685] Re: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?)
I have also tested the tarball releases from https://www.mozilla.org/firefox/ The problems are identical with those releases. I tested 94.0.2, 95.0, 96.0b2 and 97.0a1. I ran all of them with `MOZ_ENABLE_WAYLAND=1`. 94.0.2 works perfectly fine, and all the other releases show lag while scrolling, and the GNOME Shell / Mutter process even seems to lock up when Firefox starts a download, prior to the "Save file" popup window. When run on Xwayland (without the environment variable), all releases run fine. So "something" has changed between 94.0.2 and 95.0, breaking the Wayland backend at least on gen4 Intel graphics. My only other devices are Pinebook Pro's, using the Panfrost driver. I don't seem to be able to reproduce this on there. But those are arm64 builds, so maybe not the best comparison. -- 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/1953685 Title: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?) Status in firefox package in Ubuntu: New Bug description: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since the update to Firefox 95, it's been verry laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1953685/+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 1940467] Re: [snap] Nitrokey FIDO2 does not work with Chromium snap
** Changed in: snapd
Status: Fix Committed => Fix Released
** No longer affects: chromium-browser (Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1940467
Title:
[snap] Nitrokey FIDO2 does not work with Chromium snap
Status in snapd:
Fix Released
Bug description:
I have a Nitrokey FIDO2, which works fine with the Firefox deb
package. However, it does not work at all with the Chromium snap. I
have libu2f-udev installed.
This problem can be fixed by adding the following lines to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so
this is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all
Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
installed: 92.0.4515.159(1708) 148MB -
What I expected to happen: My FIDO2 security key should work.
What happened instead: It didn't work, due to a missing udev rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1940467/+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 1953685] [NEW] [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?)
Public bug reported: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since the update to Firefox 95, it's been verry laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. ** Affects: firefox (Ubuntu) Importance: Undecided Status: 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/1953685 Title: [Regression] Firefox 95 is laggy on GMA X4500 (EGL related?) Status in firefox package in Ubuntu: New Bug description: I have a couple of ThinkPads with old Intel GMA X4500 graphics. Since the update to Firefox 95, it's been verry laggy; especially noticeable while scrolling, for instance on about:support. Strangely, the bug is less present when the browser window is smaller. A maximized window lags very badly, but when resizing the window to under ~75% of the screen, it becomes a lot better. I have tried completely clean profiles by renaming ~/snap/firefox, but this made no difference. I have a feeling that EGL has something to do with it. When I force the Firefox snap to run on Xwayland by running `WAYLAND_DISABLE=1 snap run firefox`, the bug is *not* present. When I run the Firefox 95 deb (from jammy) on Wayland, by running `MOZ_ENABLE_WAYLAND=1 firefox`, the bug is also present. (When I run the deb without that environment variable, it falls back to Xwayland, which works normally.) However, when I set gfx.x11-egl.force-enabled to true in about:config, it also lags. One may assume that EGL is simply broken on this chipset, but that is not the case. When I run the Firefox *94* deb (from focal) with `MOZ_ENABLE_WAYLAND=1`, it works fine. Also, when I run `snap revert firefox` to go back to 94.0.2-2, the bug is not present, even when running on Wayland, using EGL. I have tested the snap both on focal and jammy on the same hardware. The bug is identical in both cases. tl;dr: On old Intel graphics Firefox 94 was working well with GLX and EGL, while EGL seems broken on Firefox 95. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1953685/+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 1950040] Re: Wayland Screensharing broken in Ubuntu 21.10
I noticed that both the Firefox and Chromium snaps do work in Debian 11, which uses an older xdg-desktop-portal than Ubuntu 22.04. I wondered what would happen if I'd install xdg-desktop-portal and xdg-desktop- portal-gtk 1.8 from 21.10 in 22.04, and it turns out that this fixes it. So I guess that both the Firefox and Chromium snaps are incompatible with xdg-desktop-portal 1.10. (The Firefox deb and Flatpak show the same problem by the way. Downgrading xdg-desktop-portal fixes it everywhere.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1950040 Title: Wayland Screensharing broken in Ubuntu 21.10 Status in chromium-browser package in Ubuntu: Confirmed Status in firefox package in Ubuntu: Fix Released Status in gnome-shell package in Ubuntu: Invalid Status in pipewire package in Ubuntu: Invalid Status in xdg-desktop-portal package in Ubuntu: Invalid Bug description: Freshly installed Ubuntu 21.10, screen sharing does not work with any browser, tested the following options: - Firefox snap - Firefox deb - Chromium snap - Chromium flatpak Steps to reproduce: 1. Go to https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/#7325517390736006 2. Select to share the whole desktop in the xdg-desktop-portal 3. Notice the orange screen share indicator in Gnome-Shell but actually nothing is shared in the browser. This should be handled high priority since this is a critical feature during the pandemic. Filed against ubuntu-meta since I don't know exactly which package to blame, whether it's pipewire, xdg-desktop portal or some problem directely with mutter / gnome-shell, please reassign accordingly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1950040/+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 1950040] Re: Wayland Screensharing broken in Ubuntu 21.10
@vanvugt Are you sure it works? I'm currently testing Ubuntu 22.04 (completely updated as of writing) with the 94.0.2-2 Firefox snap. When I go to https://meet.jit.si/ and click the screen sharing button, I can only select "Use operating system settings". When I do that, nothing happens. I don't get an xdg-desktop- portal popup asking me what I want to share. Simply nothing happens; basically the same as with the Firefox snap on 20.04, which doesn't have any PipeWire support in Mutter, so is expected to fail. The only relevant line in the logs is "gdk_wayland_window_configure: assertion 'height > 0' failed", just like the OP had. I've tested this with both an installed system and a live usb session. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1950040 Title: Wayland Screensharing broken in Ubuntu 21.10 Status in chromium-browser package in Ubuntu: Confirmed Status in firefox package in Ubuntu: Fix Released Status in gnome-shell package in Ubuntu: Invalid Status in pipewire package in Ubuntu: Invalid Status in xdg-desktop-portal package in Ubuntu: Invalid Bug description: Freshly installed Ubuntu 21.10, screen sharing does not work with any browser, tested the following options: - Firefox snap - Firefox deb - Chromium snap - Chromium flatpak Steps to reproduce: 1. Go to https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/#7325517390736006 2. Select to share the whole desktop in the xdg-desktop-portal 3. Notice the orange screen share indicator in Gnome-Shell but actually nothing is shared in the browser. This should be handled high priority since this is a critical feature during the pandemic. Filed against ubuntu-meta since I don't know exactly which package to blame, whether it's pipewire, xdg-desktop portal or some problem directely with mutter / gnome-shell, please reassign accordingly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1950040/+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 1915929] Re: gnome-shell-calendar-server assert failure on arm64: double free or corruption (fasttop)
This still affects me on my Pinebook Pro. Are there any plans to
backport this to focal?
--
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/1915929
Title:
gnome-shell-calendar-server assert failure on arm64: double free or
corruption (fasttop)
Status in GNOME Shell:
Unknown
Status in gnome-shell package in Ubuntu:
Fix Released
Status in gnome-shell source package in Focal:
Fix Committed
Status in gnome-shell source package in Hirsute:
Fix Released
Bug description:
[ Impact ]
gnome-shell-calendar-server crashes (and it seems to happen more in
aarch64).
https://errors.ubuntu.com/problem/028fd7df90d750d70c7fea9719974347af67fa5a
https://errors.ubuntu.com/problem/33eeeda9b48baf59fe82b6b1f0aaa9465193b7f1
[ Test case ]
There's not a clear test case, but this is relevant:
- Configure a supported calendar in your online accounts
- GNOME shell should show your events in the calendar (under notifications
panel)
[ Regression potential ]
gnome-shell-calendar-server may leak memory.
---
M1 Mac mini
Parallels Ubuntu VM
ProblemType: CrashDistroRelease: Ubuntu 21.04
Package: gnome-shell 3.38.3-2ubuntu2
ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18
Uname: Linux 5.8.0-36-generic aarch64
ApportVersion: 2.20.11-0ubuntu58
Architecture: arm64
AssertionMessage: double free or corruption (fasttop)
CasperMD5CheckResult: unknown
CrashCounter: 1
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 17 04:34:36 2021
DisplayManager: gdm3
ExecutablePath: /usr/libexec/gnome-shell-calendar-server
GsettingsChanges:
b'org.gnome.desktop.input-sources' b'sources' b"[('xkb', 'us')]"
b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'"
b'org.gnome.desktop.notifications' b'application-children' b"['apport-gtk']"
b'org.gnome.desktop.peripherals.keyboard' b'numlock-state' b'true'
InstallationDate: Installed on 2021-02-17 (0 days ago)
InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha arm64 (20210217)
ProcCmdline: /usr/libexec/gnome-shell-calendar-server
ProcEnviron:
SHELL=/bin/bash
XDG_RUNTIME_DIR=
PATH=(custom, no user)
LANG=en_US.UTF-8
RelatedPackageVersions: mutter-common 3.38.2-1ubuntu1
Signal: 6SourcePackage: gnome-shell
StacktraceTop:
__libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x81245180
"%s\n") at ../sysdeps/posix/libc_fatal.c:155
malloc_printerr (str=str@entry=0x81240c08 "double free or corruption
(fasttop)") at malloc.c:5389
_int_free (av=, p=0xe9eee300, have_lock=0) at
malloc.c:4298
g_variant_builder_clear () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
?? ()
Title: gnome-shell-calendar-server assert failure: double free or corruption
(fasttop)
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
separator:
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1915929/+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 1940467] Re: [snap] Nitrokey FIDO2 does not work with Chromium snap
Related pull request here: https://github.com/snapcore/snapd/pull/10642
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1940467
Title:
[snap] Nitrokey FIDO2 does not work with Chromium snap
Status in snapd:
Confirmed
Status in chromium-browser package in Ubuntu:
New
Bug description:
I have a Nitrokey FIDO2, which works fine with the Firefox deb
package. However, it does not work at all with the Chromium snap. I
have libu2f-udev installed.
This problem can be fixed by adding the following lines to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so
this is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all
Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
installed: 92.0.4515.159(1708) 148MB -
What I expected to happen: My FIDO2 security key should work.
What happened instead: It didn't work, due to a missing udev rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1940467/+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 1940467] Re: [snap] Nitrokey FIDO2 does not work with Chromium snap
** Description changed:
I have a Nitrokey FIDO2, which works fine with the Firefox deb package.
However, it does not work at all with the Chromium snap. I have
libu2f-udev installed.
- This problem can be fixed by adding the following line to
+ This problem can be fixed by adding the following lines to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so this
is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
- An open-source browser project that aims to build a safer, faster, and more
stable way for all
- Internet users to experience the web.
+ An open-source browser project that aims to build a safer, faster, and more
stable way for all
+ Internet users to experience the web.
commands:
- - chromium.chromedriver
- - chromium
+ - chromium.chromedriver
+ - chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
- latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
- latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
- latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
- latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
+ latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
+ latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
+ latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
+ latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
installed: 92.0.4515.159(1708) 148MB -
What I expected to happen: My FIDO2 security key should work.
What happened instead: It didn't work, due to a missing udev rule.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1940467
Title:
[snap] Nitrokey FIDO2 does not work with Chromium snap
Status in chromium-browser package in Ubuntu:
New
Bug description:
I have a Nitrokey FIDO2, which works fine with the Firefox deb
package. However, it does not work at all with the Chromium snap. I
have libu2f-udev installed.
This problem can be fixed by adding the following lines to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so
this is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all
Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
latest/candidate:
[Desktop-packages] [Bug 1940467] [NEW] [snap] Nitrokey FIDO2 does not work with Chromium snap
Public bug reported:
I have a Nitrokey FIDO2, which works fine with the Firefox deb package.
However, it does not work at all with the Chromium snap. I have
libu2f-udev installed.
This problem can be fixed by adding the following line to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so this
is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description:Ubuntu 20.04.2 LTS
Release:20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all
Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
installed: 92.0.4515.159(1708) 148MB -
What I expected to happen: My FIDO2 security key should work.
What happened instead: It didn't work, due to a missing udev rule.
** Affects: chromium-browser (Ubuntu)
Importance: Undecided
Status: New
** Tags: fido2 u2f udev
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1940467
Title:
[snap] Nitrokey FIDO2 does not work with Chromium snap
Status in chromium-browser package in Ubuntu:
New
Bug description:
I have a Nitrokey FIDO2, which works fine with the Firefox deb
package. However, it does not work at all with the Chromium snap. I
have libu2f-udev installed.
This problem can be fixed by adding the following line to
/etc/udev/rules.d/70-snap.chromium.rules:
# u2f-devices
# Nitrokey FIDO2
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="20a0",
ATTRS{idProduct}=="42b1", TAG+="snap_chromium_chromium"
TAG=="snap_chromium_chromium", RUN+="/usr/lib/snapd/snap-device-helper
$env{ACTION} snap_chromium_chromium $devpath $major:$minor"
and then running sudo udevadm control --reload-rules && sudo udevadm
trigger.
After that, it works perfectly well.
The Yubico YubiKey is already present with a very similar line, so
this is merely a case of a missing rule.
It would be very nice if support for the Nitrokey FIDO2 could be
upstreamed.
More background here: https://support.nitrokey.com/t/nitrokey-
fido2-funktioniert-nicht-mit-firefox-und-chromium-unter-
ubuntu-20-04/2651
Also hereby the required fluff:
kevin@vanadium:~$ lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04
kevin@vanadium:~$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all
Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 08:05 CEST
channels:
latest/stable:92.0.4515.159 2021-08-17 (1708) 148MB -
latest/candidate: 92.0.4515.159 2021-08-17 (1708) 148MB -
latest/beta: 93.0.4577.42 2021-08-13 (1699) 149MB -
latest/edge: 94.0.4603.0 2021-08-14 (1700) 153MB -
installed: 92.0.4515.159(1708) 148MB -
What I expected to happen: My FIDO2 security key should work.
What happened instead: It didn't work, due to a missing udev rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1940467/+subscriptions
--
[Desktop-packages] [Bug 1868117] Re: [snap] Adapt chromium user agent to avoid "not supported browser"
Will this be in the next stable channel snap update? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1868117 Title: [snap] Adapt chromium user agent to avoid "not supported browser" Status in chromium-browser package in Ubuntu: Fix Committed Bug description: Currently some websites like netflix.com and web.whatsapp.com does not recognize chromium Ubuntu as chrome because of the different user agent. We need to find a way like vivaldi to avoid such problems for casual users. Current snap chromium UA : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/80.0.3987.132 Chrome/80.0.3987.132 Safari/537.36 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1868117/+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 1872268] Re: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded)
I can confirm that setting org.gnome.desktop.privacy remember-app-usage to false, and thus removing the Frequent / All buttons, also works around this problem. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/1872268 Title: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded) Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: Confirmed Bug description: Description: Ubuntu Focal Fossa (development branch) Release: 20.04 Bug: Gnome shell while opening app drawer, clicking on an app folder and clicking on the blank area freezes gnome shell and it makes the session completely unusable and non recoverable. How to reproduce: 1- Click 9 dots on bottom corner of dash (the app launcher button), wait for the app grid to show up. 2- Click on an app folder to open it. 3- Click on the blank area outside of the opened folder dialog. 4- Gnome shell gets freezes and never come back from this state, on both wayland session and x11 session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.1-4ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu26 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Apr 12 12:00:13 2020 DisplayManager: gdm3 InstallationDate: Installed on 2020-04-11 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200329) RelatedPackageVersions: mutter-common 3.36.1-3ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1872268/+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 1872268] Re: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded)
I think part of the culprit may be that the Frequent / All buttons on the bottom are pushed downwards when opening an app folder on a 1366x768 display, causing the grid to re-align. This doesn't happen on 1280x800 or 1680x1050, where the bugs related to the many dots on the right or the shell locking up are also not present. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/1872268 Title: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded) Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: Confirmed Bug description: Description: Ubuntu Focal Fossa (development branch) Release: 20.04 Bug: Gnome shell while opening app drawer, clicking on an app folder and clicking on the blank area freezes gnome shell and it makes the session completely unusable and non recoverable. How to reproduce: 1- Click 9 dots on bottom corner of dash (the app launcher button), wait for the app grid to show up. 2- Click on an app folder to open it. 3- Click on the blank area outside of the opened folder dialog. 4- Gnome shell gets freezes and never come back from this state, on both wayland session and x11 session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.1-4ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu26 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Apr 12 12:00:13 2020 DisplayManager: gdm3 InstallationDate: Installed on 2020-04-11 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200329) RelatedPackageVersions: mutter-common 3.36.1-3ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1872268/+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 1872268] Re: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded)
This is definitely resolution related. I am unable to reproduce this on my X200's and T400's (1280x800) or T500's (1680x1050), but it hits me every time on my X220's (1366x768). I also tried gnome-shell-extension-ubuntu-dock 68 from focal-proposed, but that does not help at all. Setting org.gnome.shell.extensions.dash- to-dock extend-height to false indeed avoids the problem, but it doesn't look very nice. There seem to be more problems with GNOME Shell on this resolution. The text in the app folder icon doesn't line out nicely, and when opening the drawer, the application icons beneath it seem to re-align. When disabling the Ubuntu Dock extension, the normal GNOME dock also seems to grow and move when an app folder is opened. This does not happen on the other resolutions. Therefore, I am unsure if this is only caused by the extension. I think it's not, but the dock just makes it worse. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/1872268 Title: Gnome Shell completely freezes in Ubuntu 20.04 when clicking outside of app icon folders (when ubuntu-dock is loaded) Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: Confirmed Bug description: Description: Ubuntu Focal Fossa (development branch) Release: 20.04 Bug: Gnome shell while opening app drawer, clicking on an app folder and clicking on the blank area freezes gnome shell and it makes the session completely unusable and non recoverable. How to reproduce: 1- Click 9 dots on bottom corner of dash (the app launcher button), wait for the app grid to show up. 2- Click on an app folder to open it. 3- Click on the blank area outside of the opened folder dialog. 4- Gnome shell gets freezes and never come back from this state, on both wayland session and x11 session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.1-4ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu26 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Apr 12 12:00:13 2020 DisplayManager: gdm3 InstallationDate: Installed on 2020-04-11 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200329) RelatedPackageVersions: mutter-common 3.36.1-3ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1872268/+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 1868117] Re: [snap] Adapt chromium user agent to avoid "not supported browser"
I think everyone agrees that the 'Chromium/' part is the main problem. The snap also adds 'snap', which is an additional problem, but only removing 'snap' wouldn't help. The deb version adds 'Ubuntu' in the OS part, which the snap does not. I'm unsure if that is much of a problem. Firefox on Ubuntu also adds 'Ubuntu' after 'X11', and that doesn't seem to break many things. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1868117 Title: [snap] Adapt chromium user agent to avoid "not supported browser" Status in chromium-browser package in Ubuntu: Triaged Bug description: Currently some websites like netflix.com and web.whatsapp.com does not recognize chromium Ubuntu as chrome because of the different user agent. We need to find a way like vivaldi to avoid such problems for casual users. Current snap chromium UA : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/80.0.3987.132 Chrome/80.0.3987.132 Safari/537.36 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1868117/+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 1875172] Re: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss
It sounds like geoclue is hardly maintained upstream. And I really don't think it's a driver issue. It's common physics that tuning a radio to different channels all the time will break the transmission to and from the channel you want to tune to. In Ubuntu 18.04, this was disabled by default. Was that an upstream decision, or an Ubuntu patch? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to geoclue-2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1875172 Title: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss Status in geoclue-2.0 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location 2. In GNOME Control Center > Privacy, enable Location Services (note that I am unsure about this part; it may not even be necessary) 3. Open the application requesting your location 4. Do something latency-sensitive on WiFi, like SSH or ping Hypothesis: When an application requesting your location is running in the background and location services are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API for letting wpasupplicant scan for surrounding networks very often. This causes lots of latency spikes and visible lag. Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well. When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss. On phones connected to LTE this may make sense, but on a laptop which uses WiFi as its active network, this is detrimental to the connection. Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this problem: [wifi] enable=false On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has changed to 'true'. Expected behaviour: Don't break WiFi for a location scan. $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04 $ apt-cache policy geoclue-2.0 geoclue-2.0: Installed: 2.5.6-0ubuntu1 Candidate: 2.5.6-0ubuntu1 Version table: *** 2.5.6-0ubuntu1 500 500 http://nl.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/geoclue-2.0/+bug/1875172/+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 1868117] Re: [snap] Adapt chromium user agent to avoid "not supported browser"
I'm guessing that this patch [1] should not be added. [1] https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap- from-source/tree/build/patches/snap_useragent.patch -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1868117 Title: [snap] Adapt chromium user agent to avoid "not supported browser" Status in chromium-browser package in Ubuntu: Confirmed Bug description: Currently some websites like netflix.com and web.whatsapp.com does not recognize chromium Ubuntu as chrome because of the different user agent. We need to find a way like vivaldi to avoid such problems for casual users. Current snap chromium UA : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/80.0.3987.132 Chrome/80.0.3987.132 Safari/537.36 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1868117/+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 1868117] Re: [snap] Adapt chromium user agent to avoid "not supported browser"
Pretty much every incompatibility-related issue is solved by spoofing the user agent and removing the "snap Chromium/" part, simply claiming to be normal Chrome. There is not really any point in differentiating between Chromium and Chrome, but it breaks many websites, and it's also a nasty feature for browser fingerprinting. Identifying as Chromium will only annoy users and have them install the proprietary Chrome browser instead, so "Netflix works" and "they can join their meeting". In order to work around such issues, Vivaldi has already decided to just use Chrome's user agent, because otherwise things broke for no obvious reasons: https://vivaldi.com/blog/user-agent-changes/ Moreover, Google has decided to semi-deprecate user agents altogether in upcoming Chrome releases: https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/ https://9to5google.com/2020/01/14/google-deprecate-chrome-user-agent-string-privacy/ So with these upcoming changes in Chrome, can Chromium in Ubuntu please follow suit, and no longer differentiate from whatever string Google will use for Chrome? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1868117 Title: [snap] Adapt chromium user agent to avoid "not supported browser" Status in chromium-browser package in Ubuntu: Confirmed Bug description: Currently some websites like netflix.com and web.whatsapp.com does not recognize chromium Ubuntu as chrome because of the different user agent. We need to find a way like vivaldi to avoid such problems for casual users. Current snap chromium UA : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/80.0.3987.132 Chrome/80.0.3987.132 Safari/537.36 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1868117/+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 1868117] Re: [snap] Adapt chromium user agent to avoid "not supported browser"
Agreed, it works for Netflix, but it does not work for Teams and some other sites. There, one has to go to the Developer tools > More tools > Network conditions and change the UA there. Merely removing "snap Chromium/" fixes the issue. I guess that the UA switcher extension doesn't change the UA in JavaScript or something like that. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1868117 Title: [snap] Adapt chromium user agent to avoid "not supported browser" Status in chromium-browser package in Ubuntu: Confirmed Bug description: Currently some websites like netflix.com and web.whatsapp.com does not recognize chromium Ubuntu as chrome because of the different user agent. We need to find a way like vivaldi to avoid such problems for casual users. Current snap chromium UA : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/80.0.3987.132 Chrome/80.0.3987.132 Safari/537.36 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1868117/+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 1875172] Re: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss
https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/129 ** Bug watch added: gitlab.freedesktop.org/geoclue/geoclue/-/issues #129 https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/129 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to geoclue-2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1875172 Title: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss Status in geoclue-2.0 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location 2. In GNOME Control Center > Privacy, enable Location Services (note that I am unsure about this part; it may not even be necessary) 3. Open the application requesting your location 4. Do something latency-sensitive on WiFi, like SSH or ping Hypothesis: When an application requesting your location is running in the background and location services are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API for letting wpasupplicant scan for surrounding networks very often. This causes lots of latency spikes and visible lag. Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well. When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss. On phones connected to LTE this may make sense, but on a laptop which uses WiFi as its active network, this is detrimental to the connection. Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this problem: [wifi] enable=false On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has changed to 'true'. Expected behaviour: Don't break WiFi for a location scan. $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04 $ apt-cache policy geoclue-2.0 geoclue-2.0: Installed: 2.5.6-0ubuntu1 Candidate: 2.5.6-0ubuntu1 Version table: *** 2.5.6-0ubuntu1 500 500 http://nl.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/geoclue-2.0/+bug/1875172/+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 1875172] Re: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss
I will. But for the time being, perhaps it should be tested with more WiFi adapters? (I only have AR9380's, so I can only test ath9k.) If this is a problem for many chipsets, the default should probably be changed back to 'false'. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to geoclue-2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1875172 Title: geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss Status in geoclue-2.0 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location 2. In GNOME Control Center > Privacy, enable Location Services (note that I am unsure about this part; it may not even be necessary) 3. Open the application requesting your location 4. Do something latency-sensitive on WiFi, like SSH or ping Hypothesis: When an application requesting your location is running in the background and location services are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API for letting wpasupplicant scan for surrounding networks very often. This causes lots of latency spikes and visible lag. Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well. When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss. On phones connected to LTE this may make sense, but on a laptop which uses WiFi as its active network, this is detrimental to the connection. Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this problem: [wifi] enable=false On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has changed to 'true'. Expected behaviour: Don't break WiFi for a location scan. $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04 $ apt-cache policy geoclue-2.0 geoclue-2.0: Installed: 2.5.6-0ubuntu1 Candidate: 2.5.6-0ubuntu1 Version table: *** 2.5.6-0ubuntu1 500 500 http://nl.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/geoclue-2.0/+bug/1875172/+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 1875172] Re: gnome-weather / geoclue polls wpasupplicant SSID list too often
It's not just gnome-weather; it seems to be a more generic problem in geocule ** Package changed: gnome-weather (Ubuntu) => geoclue-2.0 (Ubuntu) ** Summary changed: - gnome-weather / geoclue polls wpasupplicant SSID list too often + geoclue polls wpasupplicant SSID list too often ** Description changed: Steps to reproduce: - 1. Install GNOME Weather (sudo apt install gnome-weather) + 1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location 2. In GNOME Control Center > Privacy, enable Location Services - 3. Open GNOME Weather at least once, so it embeds a forecast in the notifications menu + 3. Open the application requesting your location 4. Do something latency-sensitive on WiFi, like SSH or ping - Hypothesis: - When GNOME Weather is running in the background and location services - are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API - for letting wpasupplicant scan for surrounding networks very often. This - causes lots of latency spikes and visible lag. + When an application requesting your location is running in the + background and location services are enabled, it seems to tell geoclue + to use NetworkManager's D-Bus API for letting wpasupplicant scan for + surrounding networks very often. This causes lots of latency spikes and + visible lag. Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well. When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss. - Disabling location services in gnome-control-center and disabling - automatic location in gnome-weather solves this issue. + On phones connected to LTE this may make sense, but on a laptop which + uses WiFi as its active network, this is detrimental to the connection. + + Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this + problem: + + [wifi] + enable=false + + On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has + changed to 'true'. Expected behaviour: - Don't break WiFi for a weather report. - + Don't break WiFi for a location scan. $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04 - - $ apt-cache policy gnome-weather - gnome-weather: - Installed: 3.36.1-1 - Candidate: 3.36.1-1 + $ apt-cache policy geoclue-2.0 + geoclue-2.0: + Installed: 2.5.6-0ubuntu1 + Candidate: 2.5.6-0ubuntu1 Version table: - *** 3.36.1-1 500 - 500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64 Packages - 500 http://nl.archive.ubuntu.com/ubuntu focal/universe i386 Packages + *** 2.5.6-0ubuntu1 500 + 500 http://nl.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status ** Summary changed: - geoclue polls wpasupplicant SSID list too often + geoclue polls wpasupplicant SSID list too often, resulting in lag and packet loss ** Description changed: Steps to reproduce: 1. Install GNOME Weather, or GNOME Clocks, or basically anything that determines your location - 2. In GNOME Control Center > Privacy, enable Location Services + 2. In GNOME Control Center > Privacy, enable Location Services (note that I am unsure about this part; it may not even be necessary) 3. Open the application requesting your location 4. Do something latency-sensitive on WiFi, like SSH or ping Hypothesis: When an application requesting your location is running in the background and location services are enabled, it seems to tell geoclue to use NetworkManager's D-Bus API for letting wpasupplicant scan for surrounding networks very often. This causes lots of latency spikes and visible lag. Typing characters in an SSH session is rather laggy, and running something as simple as mtr 192.168.1.1 will show that every ~20 seconds the latency is over 100ms and packet loss occurs, while it's normally around 1.5ms with no packet loss. There are probably lots of other issues caused by this as well. When a WiFi adapter scans for SSID's, it has to switch channels, delaying or dropping traffic in the meanwhile. This is what causes the lag and packet loss. On phones connected to LTE this may make sense, but on a laptop which uses WiFi as its active network, this is detrimental to the connection. Changing /etc/geoclue/geoclue.conf to disable WiFi scanning, solves this problem: [wifi] enable=false On Ubuntu 18.04, this setting was the default. On Ubuntu 20.04, it has changed to 'true'. - Expected behaviour: Don't break WiFi for a location scan. $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04
[Desktop-packages] [Bug 1877073] [NEW] Stop using custom user agent, work towards generic one
Public bug reported: Ubuntu's Chromium build uses a custom user agent in many ways. It included "Ubuntu" in the .deb versions, and now it includes "snap" in the snap versions. Also, it adds a "Chromium/" field. This breaks many websites that do aggressive user agent matching, such as Netflix and Microsoft Teams. (Yes, unfortunately I have to use the latter every now and then, and I do not want to install the proprietary blob app for it.) Chromium snap's current user agent is "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/81.0.4044.129 Chrome/81.0.4044.129 Safari/537.36" While normal Chrome's current user agent is "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" Pretty much every incompatibility-related issue is solved by spoofing the user agent and removing the "snap Chromium/81.0.4044.129" part, simply claiming to be normal Chrome. There is not really any point in differentiating between Chromium and Chrome, but it breaks many websites, and it's also a nasty feature for browser fingerprinting. Identifying as Chromium will only annoy users and have them install the proprietary Chrome browser instead, so "Netflix works" and "they can join their meeting". In order to work around such issues, Vivaldi has already decided to just use Chrome's user agent, because otherwise things broke for no obvious reasons: https://vivaldi.com/blog/user-agent-changes/ Moreover, Google has decided to semi-deprecate user agents altogether in upcoming Chrome releases: https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/ https://9to5google.com/2020/01/14/google-deprecate-chrome-user-agent-string-privacy/ So with these upcoming changes in Chrome, can Chromium in Ubuntu please follow suit, and no longer differentiate from whatever string Google will use for Chrome? $ lsb_release -rd Description: Ubuntu 20.04 LTS Release: 20.04 $ snap info chromium name: chromium summary: Chromium web browser, open-source version of Chrome publisher: Canonical* store-url: https://snapcraft.io/chromium contact: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap license: unset description: | An open-source browser project that aims to build a safer, faster, and more stable way for all Internet users to experience the web. commands: - chromium.chromedriver - chromium snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R tracking: latest/stable refresh-date: 6 days ago, at 10:41 CEST channels: latest/stable:81.0.4044.129 2020-04-29 (1135) 161MB - latest/candidate: 81.0.4044.129 2020-04-28 (1135) 161MB - latest/beta: 83.0.4103.23 2020-04-25 (1125) 163MB - latest/edge: 84.0.4128.3 2020-04-29 (1136) 164MB - installed: 81.0.4044.129(1135) 161MB - ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New ** Tags: compatibility user-agent ** Description changed: Ubuntu's Chromium build uses a custom user agent in many ways. It included "Ubuntu" in the .deb versions, and now it includes "snap" in the snap versions. Also, it adds a "Chromium/" field. This breaks many websites that do agressive user agent matching, such as Netflix and Microsoft Teams. (Yes, unfortunately I have to use the latter every now and then, and I do not want to install the proprietary blob app for it.) Chromium snap's current user agent is "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/81.0.4044.129 Chrome/81.0.4044.129 Safari/537.36" While normal Chrome's current user agent is "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" - - Pretty much every user agent-related issue is solved by spoofing the user agent and removing the "snap Chromium/81.0.4044.129" part, simply claiming to be normal Chrome. There is not really any point in differentiating between Chromium and Chrome, but it breaks many websites, and it's also a nasty feature for browser fingerprinting. + Pretty much every incompatibility-related issue is solved by spoofing + the user agent and removing the "snap Chromium/81.0.4044.129" part, + simply claiming to be normal Chrome. There is not really any point in + differentiating between Chromium and Chrome, but it breaks many + websites, and it's also a nasty feature for browser fingerprinting. Identifying as Chromium will only annoy users and have them install the proprietary Chrome browser instead, so "Netflix works" and "they can join their meeting". - - In order to work around such issues, Vivaldi has already decided to just use Chrome's user agent, because otherwise things broke for no obvious reasons: + In order to work around such issues, Vivaldi has already decided to just + use Chrome's user agent, because otherwise things broke for no obvious + reasons:
[Desktop-packages] [Bug 1738149] Re: [snap] Cannot use libwidevinecdm.so to play back DRM-encrypted video
Since the Chromium 79 snap, this seems to no longer work. I have the libwidevinecdm.so from Firefox in ~/snap/chromium/current/.local/lib/, which always worked fine before, but now EME videos all just show warnings and the plugin does not seem to be loaded. Extracting the libwidevinecdm.so from a Chrome deb and putting it in the same place also does not help. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1738149 Title: [snap] Cannot use libwidevinecdm.so to play back DRM-encrypted video Status in chromium-browser package in Ubuntu: Fix Released Bug description: The chromium-browser deb package has a patch that allows the browser to look for the content decryption module in /opt/google/chrome/ and use it if present (assumes google-chrome is also installed). This won't work with the snap, because the snap's runtime environment won't use /opt from the host. What could work is to patch chromium to look for libwidevinecdm.so somewhere within the snap's area ($SNAP_USER_COMMON or $SNAP_USER_DATA), and have instructions for the user to copy the file to this area. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1738149/+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 1447654] Re: installing policykit-1 hangs under systemd
I did a couple of wily netinstalls today, and I'm still having this problem. I first have to run sudo apt-get install policykit-1, and only then I can run my postinstall scripts normally. Otherwise, I'm left with the notorious timeouts. Can't policykit-1 be installed as part of the mini.iso? Then the reboot into the installed system will probably avoid the issue. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1447654 Title: installing policykit-1 hangs under systemd Status in policykit-1 package in Ubuntu: Confirmed Status in policykit-1 source package in Vivid: Confirmed Bug description: I've installed 15.04 using the current amd64 netboot.tar.gz (MD5 = 6566065bf73a9c81feeddf5520dda122). It installs fine, but I'm getting errors installing packages (such as lubuntu-core). Last few lines from apt-get: Processing triggers for systemd (219-7ubuntu3) ... Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to execute operation: Connection timed out dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 Processing triggers for libglib2.0-0:amd64 (2.44.0-1ubuntu3) ... Processing triggers for shared-mime-info (1.3-1) ... Processing triggers for mime-support (3.58ubuntu1) ... Processing triggers for udev (219-7ubuntu3) ... Processing triggers for dbus (1.8.12-1ubuntu5) ... Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) I've done a second install using the server iso and lubuntu-core installs fine on that. The only thing different was my install media. SRU INFORMATION === Test case: - Boot a minimal VM and purge "apport policykit-1", or do the above netboot installation. - sudo apt-get install policykit-1 apport - The above hangs on the systemd triggers and eventually fails in vivid final. It should succeed fine with this update. Regression potential: Very low: polkitd does not keep state, so one can restart it fine. The postinst shell modification is simple and obvious. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1447654/+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 1442728] Re: Chromium fullscreen should be unredirected by default
As part of the big bug review for 16.04 LTS I have tested this on 15.10 and the bug is still there. ** Attachment added: "Screenshot of CCSM in a Wily VM" https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1442728/+attachment/4466059/+files/ccsm.png ** Tags added: desktop-bugscrub-triaged -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1442728 Title: Chromium fullscreen should be unredirected by default Status in Compiz: New Status in compiz package in Ubuntu: Confirmed Bug description: The default Compiz settings cause Chromium to tear when fullscreen. See also: https://code.google.com/p/chromium/issues/detail?id=344141 By default, "Unredirect Match" contains (any) & !(class=Totem) & !(class=MPlayer) & !(class=Vlc) & !(class=Plugin-container) & !(class=Firefox) This means that fullscreen Chromium videos bypass Compiz, causing them to tear (no V-sync). Firefox, Totem, VLC and MPlayer videos do not tear when fullscreen, because of the line above. Due to the popularity of the Chromium browser (and Chrome, now it has brought Netflix to Ubuntu), it should be added to the default Compiz settings, changing the line to (any) & !(class=Totem) & !(class=MPlayer) & !(class=Vlc) & !(class =Plugin-container) & !(class=Firefox) & !(class=Chromium) Most likely & !(class=^Google-chrome) should be added as well. It's very tedious to do this on each and every machine I install, and I would say that having both Firefox and Chromium be unredirected is a more sane default than just Firefox. Especially because Chromium is the only browser on Ubuntu with full MSE support and Chrome being the only way to use Netflix. To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1442728/+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 1293243] Re: Compiz causes vertical tearing
This also happens for me on i965, r600 and radeonsi, especially when running a background window with moving pixels (something like GNOME System Monitor on the Graphs tab for instance). Enabling force_swap_buffers indeed seems to make the problem go away. As part of the big bug review for 16.04 LTS I have tested this on 15.10 and the bug is still there. ** Tags added: desktop-bugscrub-triaged -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1293243 Title: Compiz causes vertical tearing Status in compiz package in Ubuntu: Confirmed Bug description: Compiz causes noticeable vertical tearing (NOT horizontal tearing) inside windows. It appears that there's a column ~450 pixels wide near the left side of the screen that is redrawn at a slightly different time. I first noticed this when scrolling and switching tabs in Chrome or Firefox. It's most visible when rapidly switching between tabs with different background colours. Enabling the "force full screen redraws (buffer swap) on repaint" workaround in CCSM fixes the issue completely. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: compiz 1:0.9.11+14.04.20140310-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6 Uname: Linux 3.13.0-17-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 331.38 Wed Jan 8 19:32:30 PST 2014 GCC version: gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) .proc.driver.nvidia.warnings.fbdev: Your system is not currently configured to drive a VGA console on the primary VGA device. The NVIDIA Linux graphics driver requires the use of a text-mode VGA console. Use of other console drivers including, but not limited to, vesafb, may result in corruption and stability problems, and is not supported. .tmp.unity.support.test.0: ApportVersion: 2.13.3-0ubuntu1 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Sun Mar 16 15:10:15 2014 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu DkmsStatus: bbswitch, 0.7, 3.13.0-15-generic, x86_64: installed bbswitch, 0.7, 3.13.0-16-generic, x86_64: installed bbswitch, 0.7, 3.13.0-17-generic, x86_64: installed bbswitch, 0.7, 3.13.0-8-generic, x86_64: installed nvidia-331, 331.38, 3.13.0-17-generic, x86_64: installed GraphicsCard: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device [1458:d000] NVIDIA Corporation GK106 [GeForce GTX 650 Ti] [10de:11c6] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ZOTAC International (MCO) Ltd. Device [19da:3288] InstallationDate: Installed on 2014-02-16 (28 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140211) MachineType: Gigabyte Technology Co., Ltd. B85M-D3H PackageArchitecture: all ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-17-generic.efi.signed root=UUID=df562f55-338f-4b20-a84b-6edd7a5002c1 ro quiet splash vt.handoff=7 SourcePackage: compiz UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/24/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F8 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: B85M-D3H dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: To be filled by O.E.M. dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF8:bd10/24/2013:svnGigabyteTechnologyCo.,Ltd.:pnB85M-D3H:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnB85M-D3H:rvrTobefilledbyO.E.M.:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.: dmi.product.name: B85M-D3H dmi.product.version: To be filled by O.E.M. dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz 1:0.9.11+14.04.20140310-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.52-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.0-1ubuntu1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.0-1ubuntu1 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A version.xserver-xorg-core: xserver-xorg-core 2:1.15.0-1ubuntu7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
[Desktop-packages] [Bug 1463598] Re: Chromium 43 fails to use hardware acceleration
Disabling WebGL is one thing, but disabling hardware acceleration altogether causes horrible tearing with each and every driver. All videos look terrible and even smooth scrolling is no longer acceptable. I've received dozens of support calls from clients about how the latest Chromium build is utterly broken, wasting hours of my life driving around and setting up the Chromium Beta PPA everywhere. Seriously, just enable the Disable WebGL flag by default instead of completely compiling out GPU support on an LTS release. These kinds of decisions are merely acceptable for daily 15.10 images, but certainly not for enterprise releases. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1463598 Title: Chromium 43 fails to use hardware acceleration Status in chromium-browser package in Ubuntu: Confirmed Bug description: After installing package chromium-browser 43.0.2357.81-0ubuntu0.14.04.1.1089 hardware acceleration becomes disabled. I had no problem with previous chromium version. Console output: jose@jose:~$ chromium-browser [3150:3191:0609/190556:ERROR:browser_gpu_channel_host_factory.cc(134)] Failed to launch GPU process. [3150:3150:0609/190556:ERROR:url_pattern_set.cc(240)] Invalid url pattern: chrome://print/* [3150:3191:0609/190556:ERROR:browser_gpu_channel_host_factory.cc(134)] Failed to launch GPU process. [3150:3191:0609/190556:ERROR:browser_gpu_channel_host_factory.cc(134)] Failed to launch GPU process. chrome://gpu: Graphics Feature Status Canvas: Software only, hardware acceleration unavailable Flash: Software only, hardware acceleration unavailable Flash Stage3D: Software only, hardware acceleration unavailable Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable Compositing: Software only, hardware acceleration unavailable Multiple Raster Threads: Unavailable Rasterization: Software only, hardware acceleration unavailable Threaded Rasterization: Unavailable Video Decode: Software only, hardware acceleration unavailable Video Encode: Software only, hardware acceleration unavailable WebGL: Unavailable Driver Bug Workarounds clear_uniforms_before_first_program_use count_all_in_varyings_packing disable_chromium_framebuffer_multisample disable_ext_occlusion_query disable_post_sub_buffers_for_onscreen_surfaces scalarize_vec_and_mat_constructor_args Problems Detected GPU process was unable to boot: GPU access is disabled in chrome://settings. Disabled Features: all - - - Actually GPU access is *not* disabled from settings. Workarounds like --disable-gpu-sandbox or LIBGL_DRI3_DISABLE=1 didn't helped at all. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1463598/+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 1447654] Re: installing policykit-1 hangs under systemd
All I have to do is a mini.iso 15.04 netinstall, install my default packages, and I can reproduce this bug on any machine I've tested. The only workaround for me is: Immediately after a netinstall: --- sudo apt-get purge policykit-1 sudo apt-get update sudo apt-get upgrade sudo systemctl reboot --- sudo apt-get install policykit-1 sudo systemctl reboot --- Install the rest of the packages I want. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1447654 Title: installing policykit-1 hangs under systemd Status in policykit-1 package in Ubuntu: Confirmed Status in policykit-1 source package in Vivid: Fix Released Bug description: I've installed 15.04 using the current amd64 netboot.tar.gz (MD5 = 6566065bf73a9c81feeddf5520dda122). It installs fine, but I'm getting errors installing packages (such as lubuntu-core). Last few lines from apt-get: Processing triggers for systemd (219-7ubuntu3) ... Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to execute operation: Connection timed out dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 Processing triggers for libglib2.0-0:amd64 (2.44.0-1ubuntu3) ... Processing triggers for shared-mime-info (1.3-1) ... Processing triggers for mime-support (3.58ubuntu1) ... Processing triggers for udev (219-7ubuntu3) ... Processing triggers for dbus (1.8.12-1ubuntu5) ... Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) I've done a second install using the server iso and lubuntu-core installs fine on that. The only thing different was my install media. SRU INFORMATION === Test case: - Boot a minimal VM and purge apport policykit-1, or do the above netboot installation. - sudo apt-get install policykit-1 apport - The above hangs on the systemd triggers and eventually fails in vivid final. It should succeed fine with this update. Regression potential: Very low: polkitd does not keep state, so one can restart it fine. The postinst shell modification is simple and obvious. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1447654/+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 1442728] Re: Chromium fullscreen should be unredirected by default
** Also affects: compiz (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1442728 Title: Chromium fullscreen should be unredirected by default Status in Compiz: New Status in compiz package in Ubuntu: New Bug description: The default Compiz settings cause Chromium to tear when fullscreen. See also: https://code.google.com/p/chromium/issues/detail?id=344141 By default, Unredirect Match contains (any) !(class=Totem) !(class=MPlayer) !(class=Vlc) !(class=Plugin-container) !(class=Firefox) This means that fullscreen Chromium videos bypass Compiz, causing them to tear (no V-sync). Firefox, Totem, VLC and MPlayer videos do not tear when fullscreen, because of the line above. Due to the popularity of the Chromium browser (and Chrome, now it has brought Netflix to Ubuntu), it should be added to the default Compiz settings, changing the line to (any) !(class=Totem) !(class=MPlayer) !(class=Vlc) !(class =Plugin-container) !(class=Firefox) !(class=Chromium) Most likely !(class=^Google-chrome) should be added as well. It's very tedious to do this on each and every machine I install, and I would say that having both Firefox and Chromium be unredirected is a more sane default than just Firefox. Especially because Chromium is the only browser on Ubuntu with full MSE support and Chrome being the only way to use Netflix. To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1442728/+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 775117] Re: Thunar hangs on first launch of each session
Just use chattr +i /usr/share/gvfs/mounts/network.mount? -- 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/775117 Title: Thunar hangs on first launch of each session Status in GVFS: New Status in Thunar file manager: Unknown Status in “gvfs” package in Ubuntu: Confirmed Status in “thunar” package in Ubuntu: Triaged Bug description: Binary package hint: thunar ** Bug Description ** Running a fresh install of Xubuntu Natty 32-bit, if I log in then launch Thunar (1.2.1-3ubuntu2), Thunar will not appear right away, and the desktop workspace will be unresponsive (excluding panels other applications). Thunar eventually appears around 20 seconds later (est.), usually accompanied by the following error popup: Launch Error The folder could not be opened Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. In the accompanying instance of Thunar, the Network item is missing from the side pane shortcut view. Depending on how long I've waited, usually the second or third Thunar launch attempt comes up very quickly, and the Network shortcut is present in the side pane. I believe this is related to XFCE Bug 7373: https://bugzilla.xfce.org/show_bug.cgi?id=7373 ** My System ** PC: HP Pavilion dv1550se laptop CPU: Intel(R) Pentium(R) M processor 1.60GHz RAM: 1GB DDR400 Video: Mobile 915GM/GMS/910GML Express Graphics Controller Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller OS: Xubuntu 11.04 i386 ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: thunar 1.2.1-3ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 Architecture: i386 Date: Sun May 1 15:07:24 2011 InstallationMedia: Xubuntu 11.04 Natty Narwhal - Release i386 (20110427) ProcEnviron: LANGUAGE=en_CA:en LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: thunar UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/775117/+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 1058987] Re: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot
*** This bug is a duplicate of bug 1061639 *** https://bugs.launchpad.net/bugs/1061639 I agree with Christian. Even though the unmount issues don't seem to happen on my testing machine anymore, shutting down still feels weird. Just shut down a 12.04 machine and compare it to a 12.10 machine. You'll just know that something is wrong. It hangs, it takes a long time, and for some people, it still causes harmful issues. And it's almost release time. Add this to the Amazon mess, and Ubuntu will have the worst publicity in years; if not ever. -- 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/1058987 Title: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot Status in “network-manager” package in Ubuntu: Incomplete Bug description: Ever since some update in the Quantal pre-releases, having dnsmasq- base installed will cause the root filesystem to not be properly unmounted on shutdown and reboot. In case the Plymouth splash screen is disabled, the message 'mount: / is busy' will be shown, but otherwise the user will not even be aware of this problem. After rebooting, the root filesystem needs recovery, as shown in dmesg: kevin@vbox-xubuntu-quantal:~$ dmesg | grep EXT4 [1.022746] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [1.022750] EXT4-fs (sda2): write access will be enabled during recovery [1.248294] EXT4-fs (sda2): recovery complete [1.248661] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [1.456315] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro Yet again, the user will not be aware of this until it is too late. The only way to avoid this from happening (or at least what I've found) is running 'sudo apt-get purge dnsmasq-base'. Sadly, this also removes network-manager and network-manager-gnome, so it isn't really a viable solution. Another problem that might be related is that having an active connection with the Network Manager prior to shutting down or rebooting, will cause the process to hang for a few seconds, after which the message about / being busy is shown. Stopping the network service (sudo service networking stop) will solve the hanging, but not the unclean unmount. So far, only purging dnsmasq-base seems to do that, which obviously also solves the other problem, as Network Manager will then also be removed. Although I haven't experienced it yet, this could cause potential data loss; especially for users without a seperate /home partition. ProblemType: Bug ApportVersion: 2.5.3-0ubuntu1 Architecture: amd64 Date: Sun Sep 30 12:49:24 2012 DistroRelease: Ubuntu 12.10 Package: dnsmasq-base 2.63-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4 SourcePackage: dnsmasq Tags: quantal Uname: Linux 3.5.0-16-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1058987/+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 1064878] Re: After X update, tty7 is very glitchy
It seems to be related to the /etc/rc.local script after all. I forgot to disable the execution bits the last time; but now I've run chmod -x, the problem really seems to be gone. I've done a fresh install and rebooted over 20 times, but I haven't seen anything weird anymore. So I think it's safe to say that running something from /etc/rc.local breaks the X session; something that didn't happen in earlier versions. ** Summary changed: - After X update, tty7 is very glitchy + After the latest X update, /etc/rc.local breaks the X session ** Description changed: - Since last night's updates, automatically logging in with LightDM causes - the screen to be blank with only a cursor shown. The desktop does appear - to be rendered on the background, because moving icons and clicking - menus (after guessing where they are) does work. The only way to get - things normal again is by restarting the lightdm service. + Since last night's updates, after booting, the screen is blank with only + a cursor shown. The desktop does appear to be rendered on the + background, because moving icons and clicking menus (after guessing + where they are) does work. The only way to get things normal again is by + restarting the lightdm service, which essentially restarts the X server. It doesn't seem to happen every time, but it does happen a lot. I have - also noticed that when manually logging in, the dmesg output on tty7 - sometimes blends in with the desktop; for instance, a black box with a - blinking cursor is shown, or when plugging in a USB thumb drive, the - output from 'mount' will be displayed, until I move my cursor over that - area. + also noticed that the dmesg output on tty7 sometimes blends in with the + desktop; for instance, a black box with a blinking cursor is shown, or + when plugging in a USB thumb drive, the output from 'mount' will be + displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). + + The problem appears to be caused by /etc/rc.local, which contains a line + to set my initial brightness. Removing everything from /etc/rc.local and + disabling the execution bit, seems to fix everything. + + In previous versions, as well as in earlier Ubuntu and Debian installs, + having this script did not cause any trouble. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) ** Tags removed: autologin blank lightdm screen -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After the latest X update, /etc/rc.local breaks the X session Status in “xorg” package in Ubuntu: Incomplete Bug description: Since last night's updates, after booting, the screen is blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service, which essentially restarts the X server. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). The problem appears to be caused by /etc/rc.local, which contains a line to set my initial brightness. Removing everything from /etc/rc.local and disabling the execution bit, seems to fix everything. In previous versions, as well as in earlier Ubuntu and Debian installs, having this script did not cause any trouble. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe :
[Desktop-packages] [Bug 1064878] [NEW] Autologin results in blank screen
Public bug reported: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. I haven't (yet) noticed anything weird when manually logging in. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when it does seem to work normally, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). P.S. When LightDM was updated, the X server was updated as well, so that might also be what causes this. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:12:05 2012 DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: lightdm Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: lightdm (Ubuntu) Importance: Undecided Status: New ** Tags: autologin blank lightdm quantal screen -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: Autologin results in blank screen Status in “lightdm” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. I haven't (yet) noticed anything weird when manually logging in. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when it does seem to work normally, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). P.S. When LightDM was updated, the X server was updated as well, so that might also be what causes this. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:12:05 2012 DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: lightdm Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+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 1064878] Re: Autologin results in blank screen
Even manually logging in is starting to become glitchy now. A black box is constantly shown, and the cursor starts disappearing every now and then. This is probably more related to the X server than to LightDM, it seems. ** Attachment added: Black box at the top left of the gtk greeter https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+attachment/3391970/+files/IMG_20121010_094129.jpg ** Summary changed: - Autologin results in blank screen + After X update, tty7 is very glitchy ** Description changed: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get - things normal again is by restarting the lightdm service. I haven't - (yet) noticed anything weird when manually logging in. + things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have - also noticed that when it does seem to work normally, the dmesg output - on tty7 sometimes blends in with the desktop; for instance, a black box - with a blinking cursor is shown, or when plugging in a USB thumb drive, - the output from 'mount' will be displayed, until I move my cursor over - that area. + also noticed that when manually logging in, the dmesg output on tty7 + sometimes blends in with the desktop; for instance, a black box with a + blinking cursor is shown, or when plugging in a USB thumb drive, the + output from 'mount' will be displayed, until I move my cursor over that + area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). - P.S. When LightDM was updated, the X server was updated as well, so that - might also be what causes this. - ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 - Date: Wed Oct 10 09:12:05 2012 + Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 - Package: lightdm 1.4.0-0ubuntu2 + Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 - SourcePackage: lightdm + SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1064878] Re: Autologin results in blank screen
** Attachment added: Console output disappearing when the cursor moves over it https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+attachment/3391952/+files/IMG_20121010_092924.jpg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: Autologin results in blank screen Status in “lightdm” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. I haven't (yet) noticed anything weird when manually logging in. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when it does seem to work normally, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). P.S. When LightDM was updated, the X server was updated as well, so that might also be what causes this. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:12:05 2012 DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: lightdm Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+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 1064878] Re: Autologin results in blank screen
It isn't visible on screenshots, so I'll add some pictures. ** Attachment added: Blinking cursor shown through the desktop https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+attachment/3391944/+files/IMG_20121010_092854.jpg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: Autologin results in blank screen Status in “lightdm” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. I haven't (yet) noticed anything weird when manually logging in. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when it does seem to work normally, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). P.S. When LightDM was updated, the X server was updated as well, so that might also be what causes this. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:12:05 2012 DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: lightdm Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+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 1064878] Re: Autologin results in blank screen
** Attachment added: Cursor is even shown on tty1 https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+attachment/3391953/+files/IMG_20121010_093145.jpg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: Autologin results in blank screen Status in “lightdm” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. I haven't (yet) noticed anything weird when manually logging in. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when it does seem to work normally, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). P.S. When LightDM was updated, the X server was updated as well, so that might also be what causes this. ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:12:05 2012 DistroRelease: Ubuntu 12.10 Package: lightdm 1.4.0-0ubuntu2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: lightdm Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1064878/+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 1064878] Re: After X update, tty7 is very glitchy
I thought that autologin made a difference, but it appears that I was wrong. This is more likely an X bug than LightDM-specific. ** Package changed: lightdm (Ubuntu) = xorg (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: New Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1064878] Re: After X update, tty7 is very glitchy
I think I've found what triggers this behaviour: I have a line in /etc/rc.local to set my initial brightness to a certain point. I believe the last update to either X or LightDM causes a race condition which triggers this bug. I have now added 'sleep 2' as the first line in /etc/rc.local, and everything seems to be normal again. Still, it might be worth looking into, as I'm most likely not the only one with such a startup script. ** Attachment added: apport.xorg.Q2aTHn.apport https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+attachment/3392419/+files/apport.xorg.Q2aTHn.apport -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: Incomplete Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1064878] Re: After X update, tty7 is very glitchy
Edit: and once again I spoke too early, as the problem is back after a reboot. I have now removed everything from /etc/rc.local, but it still happens every now and then. And I can't get apport-collect to properly work either, as it crashes as soon as I try to send the logs. Hence the one big log directly from /tmp. Apparently that is also a known bug (lp:1061493). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: Incomplete Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1049025] Re: Can't select text/highlight using mouse
This has just landed through the regular channels, and it has indeed fixed the issue. -- 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/1049025 Title: Can't select text/highlight using mouse Status in “libreoffice” package in Ubuntu: Fix Committed Bug description: In writer, if I press the left mouse button over some text, then move the mouse around with the left button still pressed, a selection is created as it should, but after less than one second this selection is discarded. However, I can select text normally using the keyboard (using SHIFT and the arrow keys). ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: libreoffice-writer 1:3.6.1~rc2-1ubuntu3 ProcVersionSignature: Ubuntu 3.5.0-14.15-generic 3.5.3 Uname: Linux 3.5.0-14-generic i686 ApportVersion: 2.5.1-0ubuntu7 Architecture: i386 Date: Tue Sep 11 11:46:41 2012 InstallationMedia: Ubuntu 10.04.1 LTS Lucid Lynx - Release i386 (20100816.1) ProcEnviron: LANGUAGE=fr:en TERM=xterm PATH=(custom, no user) LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1049025/+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 1064878] Re: After X update, tty7 is very glitchy
Switching to tty1 and moving the cursor, results in this behaviour ** Attachment added: Switching to tty1 and moving the cursor, results in this behaviour https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+attachment/3393287/+files/IMG_20121010_185425.jpg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: Incomplete Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1064878] Re: After X update, tty7 is very glitchy
** Attachment added: Logging out on tty1 confuses ConsoleKit, so the system is aware that this is not tty7 https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+attachment/3393290/+files/IMG_20121010_185528.jpg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1064878 Title: After X update, tty7 is very glitchy Status in “xorg” package in Ubuntu: Incomplete Bug description: Since last night's updates, automatically logging in with LightDM causes the screen to be blank with only a cursor shown. The desktop does appear to be rendered on the background, because moving icons and clicking menus (after guessing where they are) does work. The only way to get things normal again is by restarting the lightdm service. It doesn't seem to happen every time, but it does happen a lot. I have also noticed that when manually logging in, the dmesg output on tty7 sometimes blends in with the desktop; for instance, a black box with a blinking cursor is shown, or when plugging in a USB thumb drive, the output from 'mount' will be displayed, until I move my cursor over that area. I'm running fully up-to-date Xubuntu 12.10 (no proposed packages though) on a laptop with Intel graphics (xserver-xorg-video-intel driver). ProblemType: Bug ApportVersion: 2.6.1-0ubuntu2 Architecture: amd64 Date: Wed Oct 10 09:49:02 2012 DistroRelease: Ubuntu 12.10 Package: xserver-xorg 1:7.7+1ubuntu4 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5 SourcePackage: xorg Tags: quantal Uname: Linux 3.5.0-17-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1064878/+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 1049025] Re: Can't select text/highlight using mouse
Yes, it's still broken for me as well. And don't bother upgrading to the packages from proposed, because even though -this- bug is fixed there, many worse bugs are introduced; especially for non-Unity users. -- 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/1049025 Title: Can't select text/highlight using mouse Status in “libreoffice” package in Ubuntu: Fix Released Bug description: In writer, if I press the left mouse button over some text, then move the mouse around with the left button still pressed, a selection is created as it should, but after less than one second this selection is discarded. However, I can select text normally using the keyboard (using SHIFT and the arrow keys). ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: libreoffice-writer 1:3.6.1~rc2-1ubuntu3 ProcVersionSignature: Ubuntu 3.5.0-14.15-generic 3.5.3 Uname: Linux 3.5.0-14-generic i686 ApportVersion: 2.5.1-0ubuntu7 Architecture: i386 Date: Tue Sep 11 11:46:41 2012 InstallationMedia: Ubuntu 10.04.1 LTS Lucid Lynx - Release i386 (20100816.1) ProcEnviron: LANGUAGE=fr:en TERM=xterm PATH=(custom, no user) LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1049025/+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 1061063] Re: [FFE] Reimplement automatic appearing of CUPS queues broadcasted by a remote CUPS server
I can confirm that everything is working as before. Thanks a lot for this fix. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1061063 Title: [FFE] Reimplement automatic appearing of CUPS queues broadcasted by a remote CUPS server Status in “cups” package in Ubuntu: Fix Released Bug description: Feature Freeze Exception request for Quantal Original report: Since cups 1.6+, cups browsing protocol and automatic appearing of remote CUPS queues doesn't work anymore (LP: #1052897). This is a serious regression because each user has to : - manually add each queue of interest at every site (as printers don't appear automagically anymore) - keep a big list of non existing printers when moving (as printers don't disappear automagically anymore) The local cups server (or another daemon) should have a mean to automatically add discovered printers (like it does for USB printers for example). Rationale: The feature of CUPS servers broadcasting their print queue info into the local network and CUPS clients automatically picking up these broadcasts and making the queues immediately available and so the client always automatically having the print queues of the network where it is actually connected is unique to Linux and makes users prefer Linux against Windows or Mac. Clients are absolutely configuration-less. They simply pick up the queues in the network. Roaming with a laptop between different networks (home, office) always shows the printers actually available. In addition, it is very easy to set up high availability. Create equally-named queues on more than one server (preferably with the same printer model and configuration) and on clients only one queue (an implicit class) with this name appears and jobs get load-balanced between the servers and the queue stays alive if a part of the servers is down. As all this is done by CUPS itself, it works with all desktop applications and on the command line. No special code in the print dialogs is needed. CUPS 1.6.x dropped this feature, replacing CUPS' own broadcasting/browsing functionality by broadcasting via Bonjour (avahi-daemon). CUPS 1.6.x has no client-side browsing functionality to automatically pick up the Bonjour-bnroadcasted queues. According to upstream it requires the discovery being implemented in the application's/GUI toolkit's print dialogs, there is even a set of functions in libcups for it, but they are not used by CUPS itself. Proposed fix: In the package cups 1.6.1-0ubuntu10 I have forward-ported the removed CUPS broadcasting/browsing feature from cups 1.5.x to cups 1.6.x basing myself on the upstream SVN commits 10104, 10113, and 10544 undoing them (but without SLP and LDAP support). The patch is very large, but - It contains only code which worked well for several years in CUPS - The patch does not interfere with any changes on CUPS which were done after the removal of the CUPS Broadcasting/Browsing functionality. - It does not remove anything from the current code and also does not modify anything of the already existing functionality (like Bonjour broadcasting/AirPrint support). - I have tested it on 2 computers, one 64-bit with 17 queues and one 32-bit with one queue, having an additional Precise (CUPS 1.5.3) box in the network (~15 queues). All broadcast and receive their queues correctly and all network printing works. Equally named queues form implicit classes as expected. Left everything running over night and no crash reports in the morning (patch for bug 1041013 is also applied). - Consumers of libcups, especially GTK work without problems, so no other packages need to get rebuilt. - Eliminates the need to do changes on several GUI toolkit and application packages. - All bug fixes of 1.6.1 and after are preserved (in contrary to a downgrade to CUPS 1.5.x). Additional notes: We will not carry this large patch permanently. It is only until the GUI toolkits and print dialogs are able to discover Bonjour- broadcasted print queues and so configuration-less clients are possible without classic CUPS Broadcasting/Browsing. This we want to achieve in Quantal+1 (13.04) and so we do not need to carry this patch over to later CUPS versions. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: cups 1.6.1-0ubuntu9 [ Automatically added info not relevant for this problem removed ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1061063/+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 1058987] Re: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot
After tonight's dbus updates, still no change. -- 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/1058987 Title: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot Status in “network-manager” package in Ubuntu: Incomplete Bug description: Ever since some update in the Quantal pre-releases, having dnsmasq- base installed will cause the root filesystem to not be properly unmounted on shutdown and reboot. In case the Plymouth splash screen is disabled, the message 'mount: / is busy' will be shown, but otherwise the user will not even be aware of this problem. After rebooting, the root filesystem needs recovery, as shown in dmesg: kevin@vbox-xubuntu-quantal:~$ dmesg | grep EXT4 [1.022746] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [1.022750] EXT4-fs (sda2): write access will be enabled during recovery [1.248294] EXT4-fs (sda2): recovery complete [1.248661] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [1.456315] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro Yet again, the user will not be aware of this until it is too late. The only way to avoid this from happening (or at least what I've found) is running 'sudo apt-get purge dnsmasq-base'. Sadly, this also removes network-manager and network-manager-gnome, so it isn't really a viable solution. Another problem that might be related is that having an active connection with the Network Manager prior to shutting down or rebooting, will cause the process to hang for a few seconds, after which the message about / being busy is shown. Stopping the network service (sudo service networking stop) will solve the hanging, but not the unclean unmount. So far, only purging dnsmasq-base seems to do that, which obviously also solves the other problem, as Network Manager will then also be removed. Although I haven't experienced it yet, this could cause potential data loss; especially for users without a seperate /home partition. ProblemType: Bug ApportVersion: 2.5.3-0ubuntu1 Architecture: amd64 Date: Sun Sep 30 12:49:24 2012 DistroRelease: Ubuntu 12.10 Package: dnsmasq-base 2.63-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4 SourcePackage: dnsmasq Tags: quantal Uname: Linux 3.5.0-16-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1058987/+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 1058987] Re: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot
Just a side note: when I only purge network-manager and network-manager- gnome, but leave dnsmasq-base installed, the slow shutdown bug is solved, but the unmount problem persists. So I'm not completely sure if it's entirely caused by network-manager, as it also seems to happen when network-manager is not installed at all. If it's actually caused by dbus, it still makes sense though. -- 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/1058987 Title: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot Status in “network-manager” package in Ubuntu: In Progress Bug description: Ever since some update in the Quantal pre-releases, having dnsmasq- base installed will cause the root filesystem to not be properly unmounted on shutdown and reboot. In case the Plymouth splash screen is disabled, the message 'mount: / is busy' will be shown, but otherwise the user will not even be aware of this problem. After rebooting, the root filesystem needs recovery, as shown in dmesg: kevin@vbox-xubuntu-quantal:~$ dmesg | grep EXT4 [1.022746] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [1.022750] EXT4-fs (sda2): write access will be enabled during recovery [1.248294] EXT4-fs (sda2): recovery complete [1.248661] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [1.456315] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro Yet again, the user will not be aware of this until it is too late. The only way to avoid this from happening (or at least what I've found) is running 'sudo apt-get purge dnsmasq-base'. Sadly, this also removes network-manager and network-manager-gnome, so it isn't really a viable solution. Another problem that might be related is that having an active connection with the Network Manager prior to shutting down or rebooting, will cause the process to hang for a few seconds, after which the message about / being busy is shown. Stopping the network service (sudo service networking stop) will solve the hanging, but not the unclean unmount. So far, only purging dnsmasq-base seems to do that, which obviously also solves the other problem, as Network Manager will then also be removed. Although I haven't experienced it yet, this could cause potential data loss; especially for users without a seperate /home partition. ProblemType: Bug ApportVersion: 2.5.3-0ubuntu1 Architecture: amd64 Date: Sun Sep 30 12:49:24 2012 DistroRelease: Ubuntu 12.10 Package: dnsmasq-base 2.63-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4 SourcePackage: dnsmasq Tags: quantal Uname: Linux 3.5.0-16-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1058987/+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 1052897] Re: Printer sharing via CUPS broadcasting dropped in CUPS 1.6.x
I guess this was to be expected with Apple being in charge of CUPS. No longer having network printers automatically discovered and needing the drivers on the client-side are two of the worst regressions in Ubuntu and GNU/Linux in general that I've seen in years. Fork time? Seriously, this is bad. Ubuntu's printing system will be just like Redmond's now! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1052897 Title: Printer sharing via CUPS broadcasting dropped in CUPS 1.6.x Status in Release Notes for Ubuntu: New Status in “cups” package in Ubuntu: Fix Released Status in “system-config-printer” package in Ubuntu: Fix Released Bug description: Ever since upgrading to Quantal the 'Show printers shared by other systems' option is greyed out in System Settings - Printing. (And, perhaps redundantly, advertised printers which I saw before the upgrade, no longer appear.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1052897/+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 1049025] Re: Can't select text/highlight using mouse
This should be a high importance bug. Basic functionalities like these may not be broken, and the Quantal release isn't that far away anymore. As of today, it is still not working with the latest packages from the repositories. -- 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/1049025 Title: Can't select text/highlight using mouse Status in “libreoffice” package in Ubuntu: Triaged Bug description: In writer, if I press the left mouse button over some text, then move the mouse around with the left button still pressed, a selection is created as it should, but after less than one second this selection is discarded. However, I can select text normally using the keyboard (using SHIFT and the arrow keys). ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: libreoffice-writer 1:3.6.1~rc2-1ubuntu3 ProcVersionSignature: Ubuntu 3.5.0-14.15-generic 3.5.3 Uname: Linux 3.5.0-14-generic i686 ApportVersion: 2.5.1-0ubuntu7 Architecture: i386 Date: Tue Sep 11 11:46:41 2012 InstallationMedia: Ubuntu 10.04.1 LTS Lucid Lynx - Release i386 (20100816.1) ProcEnviron: LANGUAGE=fr:en TERM=xterm PATH=(custom, no user) LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1049025/+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 1058987] Re: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot
I've just installed the updates; and it doesn't make any difference for me. I also tried reinstalling network-manager, network-manager-gnome and dnsmasq-base, but still nothing. I'll try a clean install in VirtualBox tonight. -- 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/1058987 Title: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot Status in “network-manager” package in Ubuntu: Incomplete Bug description: Ever since some update in the Quantal pre-releases, having dnsmasq- base installed will cause the root filesystem to not be properly unmounted on shutdown and reboot. In case the Plymouth splash screen is disabled, the message 'mount: / is busy' will be shown, but otherwise the user will not even be aware of this problem. After rebooting, the root filesystem needs recovery, as shown in dmesg: kevin@vbox-xubuntu-quantal:~$ dmesg | grep EXT4 [1.022746] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [1.022750] EXT4-fs (sda2): write access will be enabled during recovery [1.248294] EXT4-fs (sda2): recovery complete [1.248661] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [1.456315] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro Yet again, the user will not be aware of this until it is too late. The only way to avoid this from happening (or at least what I've found) is running 'sudo apt-get purge dnsmasq-base'. Sadly, this also removes network-manager and network-manager-gnome, so it isn't really a viable solution. Another problem that might be related is that having an active connection with the Network Manager prior to shutting down or rebooting, will cause the process to hang for a few seconds, after which the message about / being busy is shown. Stopping the network service (sudo service networking stop) will solve the hanging, but not the unclean unmount. So far, only purging dnsmasq-base seems to do that, which obviously also solves the other problem, as Network Manager will then also be removed. Although I haven't experienced it yet, this could cause potential data loss; especially for users without a seperate /home partition. ProblemType: Bug ApportVersion: 2.5.3-0ubuntu1 Architecture: amd64 Date: Sun Sep 30 12:49:24 2012 DistroRelease: Ubuntu 12.10 Package: dnsmasq-base 2.63-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4 SourcePackage: dnsmasq Tags: quantal Uname: Linux 3.5.0-16-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1058987/+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 1058987] Re: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot
Tested this in VirtualBox: Custom Xubuntu 12.10 installation (netinst with Xfce packages) - fully updated: not fixed Stock Ubuntu 12.10 installation (installed with ubiquity, unmodified) - fully updated: not fixed Stock Xubuntu 12.10 installation (installed with ubiquity, unmodified) - fully updated: not fixed Fresh custom Xubuntu 12.10 installation (latest netinst with Xfce packages) - fully updated (while installing): not fixed Tested this on my testing machine: Custom Xubuntu 12.10 installation (netinst with Xfce packages) - fully updated: not fixed Stock Xubuntu 12.10 installation (installed with ubiquity, unmodified) - fully updated: not fixed Fresh custom Xubuntu 12.10 installation (latest netinst with Xfce packages) - fully updated (while installing): not fixed In each and every case, purging dnsmasq-base solves all issues. Purging only network-manager only solves the long shutdown time, but not the unmounting issue. Am I really the only one noticing the huge increase in shutdown time compared to 12.04, and hasn't anyone else seen fsck show up in every dmesg 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/1058987 Title: In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot Status in “network-manager” package in Ubuntu: Incomplete Bug description: Ever since some update in the Quantal pre-releases, having dnsmasq- base installed will cause the root filesystem to not be properly unmounted on shutdown and reboot. In case the Plymouth splash screen is disabled, the message 'mount: / is busy' will be shown, but otherwise the user will not even be aware of this problem. After rebooting, the root filesystem needs recovery, as shown in dmesg: kevin@vbox-xubuntu-quantal:~$ dmesg | grep EXT4 [1.022746] EXT4-fs (sda2): INFO: recovery required on readonly filesystem [1.022750] EXT4-fs (sda2): write access will be enabled during recovery [1.248294] EXT4-fs (sda2): recovery complete [1.248661] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [1.456315] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro Yet again, the user will not be aware of this until it is too late. The only way to avoid this from happening (or at least what I've found) is running 'sudo apt-get purge dnsmasq-base'. Sadly, this also removes network-manager and network-manager-gnome, so it isn't really a viable solution. Another problem that might be related is that having an active connection with the Network Manager prior to shutting down or rebooting, will cause the process to hang for a few seconds, after which the message about / being busy is shown. Stopping the network service (sudo service networking stop) will solve the hanging, but not the unclean unmount. So far, only purging dnsmasq-base seems to do that, which obviously also solves the other problem, as Network Manager will then also be removed. Although I haven't experienced it yet, this could cause potential data loss; especially for users without a seperate /home partition. ProblemType: Bug ApportVersion: 2.5.3-0ubuntu1 Architecture: amd64 Date: Sun Sep 30 12:49:24 2012 DistroRelease: Ubuntu 12.10 Package: dnsmasq-base 2.63-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4 SourcePackage: dnsmasq Tags: quantal Uname: Linux 3.5.0-16-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1058987/+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 1047280] Re: Show printers shared by other systems box is greyed out
The recent updates have simply removed the checkbox from system-config- printer-gnome. Admittedly, you can manually add network printers by entering the IP address of the local print server (or whichever computer has the printer connected to it), but printers still do not show up automatically. Also, printer drivers now have to be locally installed (printer-driver-hpcups for instance), whereas the drivers only had to be installed on the server-side in the past. CUPS is starting to behave like Microsoft Windows' printing system. This is a big regression in usability, and the now gone ease of network printing is a lost selling point of why GNU/Linux is better than Windows. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to system-config-printer in Ubuntu. https://bugs.launchpad.net/bugs/1047280 Title: Show printers shared by other systems box is greyed out Status in “system-config-printer” package in Ubuntu: Confirmed Bug description: Since upgrading to quantal the Show printers shared by other systems box is greyed out under the print settings. There doesn't seem to be any way to change this. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: system-config-printer-common 1.3.11+20120807-0ubuntu6 ProcVersionSignature: Ubuntu 3.5.0-13.14-generic 3.5.3 Uname: Linux 3.5.0-13-generic i686 ApportVersion: 2.5.1-0ubuntu4 Architecture: i386 CheckboxSubmission: e9bd5d0c11367f73e7718b1ea675f7ba CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f CupsErrorLog: Date: Fri Sep 7 11:47:59 2012 InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Beta i386 (20110921.2) Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: p11-kit: duplicate configured module: gnome-keyring.module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so lpstat: No destinations added. MachineType: LENOVO 4287CTO PackageArchitecture: all Papersize: a4 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-13-generic root=UUID=0021680f-1924-4d38-986d-52d44d79c9fd ro quiet splash vt.handoff=7 SourcePackage: system-config-printer UpgradeStatus: Upgraded to quantal on 2012-09-05 (2 days ago) dmi.bios.date: 07/07/2011 dmi.bios.vendor: LENOVO dmi.bios.version: 8DET50WW (1.20 ) dmi.board.asset.tag: Not Available dmi.board.name: 4287CTO 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:bvr8DET50WW(1.20):bd07/07/2011:svnLENOVO:pn4287CTO:pvrThinkPadX220:rvnLENOVO:rn4287CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4287CTO dmi.product.version: ThinkPad X220 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1047280/+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 727415] Re: Disk Utility tries to launch Nautilus
This seems fixed in Xubuntu 12.10. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-disk-utility in Ubuntu. https://bugs.launchpad.net/bugs/727415 Title: Disk Utility tries to launch Nautilus Status in gnome-disk-utility: New Status in “gnome-disk-utility” package in Ubuntu: Triaged Status in Gentoo Linux: Fix Released Bug description: Binary package hint: gnome-disk-utility Disk Utility (palimpsest) defaults to opening Nautilus when clicking on a mount link. If you don't use Nautilus then this produces an error. Steps to reproduce: 1. Open palimpsest 2. Pick a partition (or mount one) 3. Scroll down to the Mount Point section 4. Click on the link to open the mount 5. Error - Nautilus is not found I'm not sure if it's possible to use a generic link not specific to looking for Nautilus (or some other mechanism), but it probably is. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: gnome-disk-utility 2.30.1-2 ProcVersionSignature: Ubuntu 2.6.35-25.44-generic 2.6.35.10 Uname: Linux 2.6.35-25-generic i686 Architecture: i386 Date: Tue Mar 1 20:44:53 2011 InstallationMedia: Lubuntu 10.10 Maverick Meerkat - i386 (20101010) ProcEnviron: PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: gnome-disk-utility To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-disk-utility/+bug/727415/+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 1058623] [NEW] APM settings are not persistent after a reboot
Public bug reported:
In order to keep my data storage disks from slowly committing suicide by
unloading their heads, I have to disable APM for both of them. Usually I
would be able to do so by putting 'hdparm -B255 -S0 /dev/sdx*' in
/etc/rc.local.
Since Ubuntu 12.10, Palimpsest has a built-in function to modify APM
settings if required. Sadly, after a reboot, these settings aren't kept.
Even though the Palimpsest interface still claims APM is set to 255,
running sudo hdparm -I /dev/sdx* will show the default value of 128
again. The desired behaviour is hdparm showing 'APM = off', and, more
importantly, the disks not breaking themselves.
The only way to keep my disks from dying is by adding
/dev/sdx* {
apm = 255
spindown_time = 0
}
to /etc/hdparm.conf, as everything in /etc/rc.local seems to be ignored
as well. The problem is no different for my SSD, but it doesn't make a
difference for that one, obviously. Disabling and re-enabling the APM
settings from Palimpsest does seem to work though, but it's impossible
to do/remember that after every bootup. And forgetting to do so would
most likely lead to premature disk failure.
* 'sdx' is 'sdb' and 'sdc' in my case
ProblemType: Bug
ApportVersion: 2.5.3-0ubuntu1
Architecture: amd64
Date: Sat Sep 29 15:28:24 2012
DistroRelease: Ubuntu 12.10
Package: gnome-disk-utility 3.6.0-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.5.0-16.24-generic 3.5.4
SourcePackage: gnome-disk-utility
Tags: quantal
Uname: Linux 3.5.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: gnome-disk-utility (Ubuntu)
Importance: Undecided
Status: New
** Tags: apm disk gnome quantal utility
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-disk-utility in Ubuntu.
https://bugs.launchpad.net/bugs/1058623
Title:
APM settings are not persistent after a reboot
Status in “gnome-disk-utility” package in Ubuntu:
New
Bug description:
In order to keep my data storage disks from slowly committing suicide
by unloading their heads, I have to disable APM for both of them.
Usually I would be able to do so by putting 'hdparm -B255 -S0
/dev/sdx*' in /etc/rc.local.
Since Ubuntu 12.10, Palimpsest has a built-in function to modify APM
settings if required. Sadly, after a reboot, these settings aren't
kept. Even though the Palimpsest interface still claims APM is set to
255, running sudo hdparm -I /dev/sdx* will show the default value of
128 again. The desired behaviour is hdparm showing 'APM = off', and,
more importantly, the disks not breaking themselves.
The only way to keep my disks from dying is by adding
/dev/sdx* {
apm = 255
spindown_time = 0
}
to /etc/hdparm.conf, as everything in /etc/rc.local seems to be
ignored as well. The problem is no different for my SSD, but it
doesn't make a difference for that one, obviously. Disabling and re-
enabling the APM settings from Palimpsest does seem to work though,
but it's impossible to do/remember that after every bootup. And
forgetting to do so would most likely lead to premature disk failure.
* 'sdx' is 'sdb' and 'sdc' in my case
ProblemType: Bug
ApportVersion: 2.5.3-0ubuntu1
Architecture: amd64
Date: Sat Sep 29 15:28:24 2012
DistroRelease: Ubuntu 12.10
Package: gnome-disk-utility 3.6.0-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.5.0-16.24-generic 3.5.4
SourcePackage: gnome-disk-utility
Tags: quantal
Uname: Linux 3.5.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1058623/+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 775117] Re: Thunar hangs on first launch of each session
This is still present in 12.10 and still has to be fixed quickly in my opinion. Modifying /usr/share/gvfs/mounts/network.mount has three clear downsides; it has to be done on every machine after every clean install (so basically twice a year on all your computers); it puts an ugly broken-file icon with the text network:// in the side pane (which simply looks amateuristic), and local changes are overwritten on every update of gvfs-backends. Nautilus, on the other hand, works fine without modifying any file. Why can't Thunar act the way Nautilus does? Clicking the network icon in Nautilus will render the short delay; not the initial startup. -- 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/775117 Title: Thunar hangs on first launch of each session Status in GVFS: New Status in Thunar file manager: Unknown Status in “gvfs” package in Ubuntu: Confirmed Status in “thunar” package in Ubuntu: Triaged Bug description: Binary package hint: thunar ** Bug Description ** Running a fresh install of Xubuntu Natty 32-bit, if I log in then launch Thunar (1.2.1-3ubuntu2), Thunar will not appear right away, and the desktop workspace will be unresponsive (excluding panels other applications). Thunar eventually appears around 20 seconds later (est.), usually accompanied by the following error popup: Launch Error The folder could not be opened Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. In the accompanying instance of Thunar, the Network item is missing from the side pane shortcut view. Depending on how long I've waited, usually the second or third Thunar launch attempt comes up very quickly, and the Network shortcut is present in the side pane. I believe this is related to XFCE Bug 7373: https://bugzilla.xfce.org/show_bug.cgi?id=7373 ** My System ** PC: HP Pavilion dv1550se laptop CPU: Intel(R) Pentium(R) M processor 1.60GHz RAM: 1GB DDR400 Video: Mobile 915GM/GMS/910GML Express Graphics Controller Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller OS: Xubuntu 11.04 i386 ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: thunar 1.2.1-3ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 Architecture: i386 Date: Sun May 1 15:07:24 2011 InstallationMedia: Xubuntu 11.04 Natty Narwhal - Release i386 (20110427) ProcEnviron: LANGUAGE=en_CA:en LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: thunar UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/775117/+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 1057028] [NEW] glines doesn't save window dimensions, default size is much too small
Public bug reported: As with most other GNOME games, glines does not save the window dimensions. For the regular board size, the default window size is all right, but when selecting a larger board size, the default window size makes the game pretty much unplayable. The window has to be maximized or resized after every start in order for the application to become even somewhat useful. Either the window dimensions should be saved, or a larger default size should be used for larger board sizes. ProblemType: Bug ApportVersion: 2.5.2-0ubuntu4 Architecture: amd64 Date: Wed Sep 26 18:39:26 2012 DistroRelease: Ubuntu 12.10 Package: glines 1:3.5.90-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-15.23-generic 3.5.4 SourcePackage: gnome-games Tags: quantal Uname: Linux 3.5.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-games (Ubuntu) Importance: Undecided Status: New ** Tags: dimensions glines quantal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/1057028 Title: glines doesn't save window dimensions, default size is much too small Status in “gnome-games” package in Ubuntu: New Bug description: As with most other GNOME games, glines does not save the window dimensions. For the regular board size, the default window size is all right, but when selecting a larger board size, the default window size makes the game pretty much unplayable. The window has to be maximized or resized after every start in order for the application to become even somewhat useful. Either the window dimensions should be saved, or a larger default size should be used for larger board sizes. ProblemType: Bug ApportVersion: 2.5.2-0ubuntu4 Architecture: amd64 Date: Wed Sep 26 18:39:26 2012 DistroRelease: Ubuntu 12.10 Package: glines 1:3.5.90-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-15.23-generic 3.5.4 SourcePackage: gnome-games Tags: quantal Uname: Linux 3.5.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/1057028/+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 1057028] Re: glines doesn't save window dimensions, default size is much too small
** Attachment added: Large board size with default dimensions under Xubuntu 12.10 https://bugs.launchpad.net/bugs/1057028/+attachment/3345962/+files/Screenshot%20-%20092612%20-%2018%3A36%3A44.png -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/1057028 Title: glines doesn't save window dimensions, default size is much too small Status in “gnome-games” package in Ubuntu: New Bug description: As with most other GNOME games, glines does not save the window dimensions. For the regular board size, the default window size is all right, but when selecting a larger board size, the default window size makes the game pretty much unplayable. The window has to be maximized or resized after every start in order for the application to become even somewhat useful. Either the window dimensions should be saved, or a larger default size should be used for larger board sizes. ProblemType: Bug ApportVersion: 2.5.2-0ubuntu4 Architecture: amd64 Date: Wed Sep 26 18:39:26 2012 DistroRelease: Ubuntu 12.10 Package: glines 1:3.5.90-0ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.5.0-15.23-generic 3.5.4 SourcePackage: gnome-games Tags: quantal Uname: Linux 3.5.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/1057028/+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 1055766] Re: grep -R doesn't automatically search amazon
I agree with Tony Narlock. After all, you only have to run sudo apt-get
purge unity-lens-shopping unity-scope-musicstores unity-webapps-common
rm ~/.local/share/applications/Amazonwwwamazoncom.desktop in order to
get rid of all the search suggestions and web apps. If those three
packages wouldn't be installed by default and the .desktop file wouldn't
be created, no one would mind anymore. A checkbox just like the fluendo
decoder would be a great idea. You could even come up with a description
of how it might be useful etc. Just keep it out of the ubuntu-desktop
and unity packages.
--
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/1055766
Title:
grep -R doesn't automatically search amazon
Status in Ayatana Design:
Invalid
Status in “command-not-found” package in Ubuntu:
Invalid
Status in “gnome-terminal” package in Ubuntu:
Invalid
Status in “grep” package in Debian:
New
Bug description:
Dear root owning overlords,
When using grep recursively I only get local results:
grep -R fish_t /home/noob/fish_game/*
/home/noob/fish_game/fish.h: struct fish_t {
/home/noob/fish_game/fish.c: struct fish_t eric_the_ fish;
or worse:
grep -R shark_t /home/noob/fish_game/*
/home/noob/fish_game/fish.h: struct shark_t {
/home/noob/fish_game/fish.c: struct shark_t_t mark_sw;
I declare this a bug for two reasons:
1. The output is boring.
2. The terminal has more than 2 lines!!! It's an unefficient use of my
screenspace.
I believe the reason for this is that the grep command only searches
locally for things I am actually looking for, I kind of expect the
results I get from my codebase and as such it removes any sense of
mystery or something new and exciting to spice up my dull geek
existence. That's boring, grep -R should also search amazon, so I get
more exciting results such as:
Shark Season 1 Starring Steven Eckholdt, Nora Dunn, Patrick Fabian, et al.
Amazon Instant Video
to buy episodes: $1.99
to buy season: $34.99 ($1.59 per episode)
Watch instantly on your PC, Mac, compatible TV or device.
2.
Product Details
See Color Size Options
NHL San Jose Sharks Primary Logo T-Shirt Men's by Reebok
$16.95 - $19.99
new from $16.95
(1)
Eligible for FREE Super Saver Shipping.
3.
Product Details
See Size Options
Shark Week Girls T-Shirt by Hot Topic
$22.50
See all 9,755 results
struct shark_t (See all 1,583 results)
1.
Product Details
See Size Options
D:fi D:struct Pliable Molding Creme by D:Fi
$23.50 $17.05 ($11.37/100 g)
new from $10.50
Only 7 left in stock - order soon.
(35)
Eligible for FREE Super Saver Shipping.
2.
Product Details
Take 'N' Play Anywhere Activities Activity Tin - Robo-struct by Patch Products
$11.99 $8.77
new from $3.99
Order in the next 1 hour and get it by Tuesday, Sep 25.
Only 12 left in stock - order soon.
(1)
Eligible for FREE Super Saver Shipping.
Manufacturer recommended age: 4 - 9 Years
3.
Product Details
d:fi d:struct 2.65 oz by AMERICAN CREW
This is less dull and also maximises the use of my terminal and hence
increases my productivity.
Please can you change the grep warez to have this feature, and just
install it on my machine while I'm down the pub, after all you do
erm, have root, so it should be easy for you to do :-)
Thanks Ubuntu devs!!!
Sent from my Unity device, (which is why it took several glacial ages
and a couple of eras to get it done)
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-terminal 3.0.1-0ubuntu3
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu3
Architecture: i386
Date: Mon Sep 24 22:20:29 2012
ExecutablePath: /usr/bin/gnome-terminal
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111012)
SourcePackage: gnome-terminal
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ayatana-design/+bug/1055766/+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 1052897] Re: 'Show printers shared by other systems' greyed out after quantal upgrade
The checkbox to enable showing printers shared by other systems also seems to be gone from localhost:631/admin, and enabling local printer sharing currently breaks CUPS entirely: the system-config-printer-gnome applet will no longer connect to CUPS, and localhost:631 will reject the connection (Error 102 with Chromium). The only way to be able to log in again is to purge and reinstall the cups package. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1052897 Title: 'Show printers shared by other systems' greyed out after quantal upgrade Status in “cups” package in Ubuntu: Confirmed Bug description: Ever since upgrading to Quantal the 'Show printers shared by other systems' option is greyed out in System Settings - Printing. (And, perhaps redundantly, advertised printers which I saw before the upgrade, no longer appear.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1052897/+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
