[Touch-packages] [Bug 1977695] [NEW] Black Screen on Boot with X11
Public bug reported: Description:Ubuntu 22.04 LTS Release:22.04 xorg: Installed: 1:7.7+23ubuntu2 Candidate: 1:7.7+23ubuntu2 Version table: *** 1:7.7+23ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status 1. Uncomment WaylandEnable=false in /etc/gdm3/custom.conf 2. Reboot. 3. See black screen after selecting Ubuntu at GRUB prompt. Login screen never loads. Unplugging any external monitors appears to have no effect on the bug. I am aware that most users of Ubuntu 22.04 see an option at the login screen to change the display manager. I have never seen such an option. My machine always uses Wayland unless I modify /etc/gdm3/custom.conf directly. Using Wayland is detrimental to my health, because the Night Light feature does nothing. I have nvidia-driver-510 installed. I am happy to provide further debugging information upon request. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..01.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 510.73.05 Sat May 7 05:30:26 UTC 2022 GCC version: ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sun Jun 5 15:47:31 2022 DistUpgraded: 2022-05-07 18:27:00,043 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 630 [103c:8259] Subsystem: Hewlett-Packard Company GP107M [GeForce GTX 1050 Mobile] [103c:8259] InstallationDate: Installed on 2020-12-09 (543 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) MachineType: HP OMEN by HP Laptop ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.15.0-35-generic root=UUID=13d7b775-7783-44fc-8e24-164127457fd4 ro rootflags=subvol=@ quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: Upgraded to jammy on 2022-05-08 (28 days ago) dmi.bios.date: 12/22/2020 dmi.bios.release: 15.56 dmi.bios.vendor: Insyde dmi.bios.version: F.56 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 8259 dmi.board.vendor: HP dmi.board.version: 83.72 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 83.72 dmi.modalias: dmi:bvnInsyde:bvrF.56:bd12/22/2020:br15.56:efr83.72:svnHP:pnOMENbyHPLaptop:pvrType1ProductConfigId:rvnHP:rn8259:rvr83.72:cvnHP:ct10:cvrChassisVersion:skuW2N35UAR#ABA: dmi.product.family: 103C_5335KV HP Omen dmi.product.name: OMEN by HP Laptop dmi.product.sku: W2N35UAR#ABA dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2 version.libgl1-mesa-glx: libgl1-mesa-glx 22.0.1-1ubuntu2 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ubuntu wayland-session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1977695 Title: Black Screen on Boot with X11 Status in xorg package in Ubuntu: New Bug description: Description: Ubuntu 22.04 LTS Release: 22.04 xorg: Installed: 1:7.7+23ubuntu2 Candidate: 1:7.7+23ubuntu2 Version table: *** 1:7.7+23ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status 1. Uncomment WaylandEnable=false in /etc/gdm3/custom.conf 2. Reboot. 3. See black screen after selecting Ubuntu at GRUB
[Touch-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 Ubuntu Touch seeded 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.
[Touch-packages] [Bug 1810499] Re: Provide a function to undo all upgrades of proposed packages
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: software-properties (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1810499 Title: Provide a function to undo all upgrades of proposed packages Status in software-properties package in Ubuntu: Confirmed Bug description: While packages which are upgraded by versions delivered by a PPA are easy to downgrade with `ppa-purge` an equivalent function is missing for packages installed from `proposed` after it has been activated. Afaik the overview provided at https://askubuntu.com/questions/59443/how-can-i-revert-back-from-an- upgrade-to-the-proposed-repository is still the current state. The switch to `proposed` can be an easy way to fix issues, however once the fix makes it into an `-updates` repository it is a legitimate use case to stop using `proposed` packages since they can be troublesome. It'd be nice to automate the function provided by the scripts listed in the askubuntu.com post in a maintained official Ubuntu software. Most of the functionality is probably provided in `ppa-purge` already. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: software-properties-common 0.96.27 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu13.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Jan 4 10:56:18 2019 InstallationDate: Installed on 2018-10-29 (66 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) PackageArchitecture: all ProcEnviron: LANG=de_DE.UTF-8 SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= PATH=(custom, no user) SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1810499/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-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
[Touch-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/;
[Touch-packages] [Bug 1977689] [NEW] Wrong error msg: "state file /var/lib/logrotate/status is world-readable" although it is not
Public bug reported: Ubuntu 22.04 logrotate 3.19.0-1ubuntu1.1 Every hour, I receive this wrong message: Subject:Cron >cd / && run-parts --report /etc/cron.hourly /etc/cron.hourly/logrotate: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... despite: # ls -al /var/lib/logrotate total 40 drwxr-x--- 2 root root 4096 Jun 5 17:17 . drwxr-xr-x 66 root root 4096 Jun 3 20:02 .. -rw-r- 1 root root 31974 Jun 5 17:17 status ** Affects: logrotate (Ubuntu) Importance: Undecided Status: New ** Description changed: Ubuntu 22.04 logrotate 3.19.0-1ubuntu1.1 Every hour, I receive this wrong message: + + Subject: Cron >cd / && run-parts --report /etc/cron.hourly /etc/cron.hourly/logrotate: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... despite: # ls -al /var/lib/logrotate total 40 drwxr-x--- 2 root root 4096 Jun 5 17:17 . drwxr-xr-x 66 root root 4096 Jun 3 20:02 .. -rw-r- 1 root root 31974 Jun 5 17:17 status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to logrotate in Ubuntu. https://bugs.launchpad.net/bugs/1977689 Title: Wrong error msg: "state file /var/lib/logrotate/status is world- readable" although it is not Status in logrotate package in Ubuntu: New Bug description: Ubuntu 22.04 logrotate 3.19.0-1ubuntu1.1 Every hour, I receive this wrong message: Subject: Cron >cd / && run-parts --report /etc/cron.hourly /etc/cron.hourly/logrotate: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... despite: # ls -al /var/lib/logrotate total 40 drwxr-x--- 2 root root 4096 Jun 5 17:17 . drwxr-xr-x 66 root root 4096 Jun 3 20:02 .. -rw-r- 1 root root 31974 Jun 5 17:17 status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1977689/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-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. + *
[Touch-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 Ubuntu Touch seeded 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
[Touch-packages] [Bug 1958019] Re: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all
Speakers are working for me now after installing the BIOS update from 2022-06-02. https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/legion- series/legion-7-16achg6/downloads/driver-list/component?name=BIOS%2FUEFI I booted on windows, installed the update and after switching to Linux the speakers instantly worked without any problems. Not sure if installing the update alone did the trick since I tried a lot before without success... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2021 dmi.bios.release: 1.49 dmi.bios.vendor: LENOVO dmi.bios.version: GKCN49WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0R32862 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion 7 16ACHg6 dmi.ec.firmware.release: 1.49 dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6: dmi.product.family: Legion 7 16ACHg6 dmi.product.name: 82N6 dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 dmi.product.version: Legion 7 16ACHg6 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/sound-2.6/+bug/1958019/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1965439] Re: applications can no longer launch when called by kdesu
Confirmed facing this bug. I managed to use the .desktop file workaround for Discover, but it does not seem to work for Muon. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1965439 Title: applications can no longer launch when called by kdesu Status in kdesu package in Ubuntu: Fix Released Status in kubuntu-settings package in Ubuntu: Fix Released Status in sudo package in Ubuntu: Confirmed Status in ubuntustudio-default-settings package in Ubuntu: Fix Released Status in kdesu source package in Jammy: In Progress Status in kubuntu-settings source package in Jammy: In Progress Status in sudo source package in Jammy: Confirmed Status in ubuntustudio-default-settings source package in Jammy: In Progress Status in kdesu source package in Kinetic: Fix Released Status in kubuntu-settings source package in Kinetic: Fix Released Status in sudo source package in Kinetic: Confirmed Status in ubuntustudio-default-settings source package in Kinetic: Fix Released Status in kdesu package in Debian: Fix Released Bug description: See description below. As the driver manager is done inside software- properties-qt, it's basically the same bug, but now it's affected by something we can't exactly get into the mechanism of: plasma- discover's "Software Sources" link. Steps to recrate: 1) Open Plasma-discover 2) Go to Settings 3) Under click on "Software Sources" 4) Attempt to enter password Expected: Software properties opens Actual: Pkexec keeps asking for password. -- Earlier description: The driver manager for both Ubuntu Studio and Kubuntu can no longer launch due to some updated security measures in PolicyKit. The original behavior was that systemsettings would open /usr/bin/ubuntustudio-driver-manager (or /usr/bin/kubuntu-driver- manger) via pkexec, which would then open software-settings-qt. Unfortunately, the new behavior does not act correctly to pkexec and pkexec does not see the user as available in the sudoers file. The only way around this was to pass "export DISPLAY=:0" inside the appropriate driver manager executable with the command "sudo software- properties-qt". The KCM itself needs to execute the driver-manager via xterm, which then prompts for a password. It's ugly, but it works. I will attach a debdiff for the kubuntu-settings package. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubuntustudio-default-settings 22.04.19 [modified: usr/share/sddm/themes/ubuntustudio/theme.conf] ProcVersionSignature: Ubuntu 5.15.0-22.22-lowlatency 5.15.19 Uname: Linux 5.15.0-22-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Thu Mar 17 12:19:44 2022 InstallationDate: Installed on 2021-03-20 (361 days ago) InstallationMedia: Ubuntu-Studio 21.04 "Hirsute Hippo" - Alpha amd64 (20210320) PackageArchitecture: all SourcePackage: ubuntustudio-default-settings UpgradeStatus: Upgraded to jammy on 2021-11-07 (130 days ago) modified.conffile..etc.skel..local.share.konsole.Profile: [deleted] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdesu/+bug/1965439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977685] [NEW] sound card Everest ESSX8336 not supported
Public bug reported: I work with Ubuntu 22.04 but the Everest semiconductor Co Ltd ESSX8336\1 sound card is not recognized. On the web a lot of people have the same problem. It's an annoying problem. Could you please help us to solve this problem. I have a Huawei Matebook D15 series Matebook D 15 (2021) i3 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: francois852 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jun 5 15:44:25 2022 InstallationDate: Installed on 2022-04-22 (43 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/21/2022 dmi.bios.release: 1.41 dmi.bios.vendor: HUAWEI dmi.bios.version: 1.41 dmi.board.asset.tag: NULL dmi.board.name: BOHB-WAX9-PCB-B2 dmi.board.vendor: HUAWEI dmi.board.version: M1340 dmi.chassis.asset.tag: NULL dmi.chassis.type: 10 dmi.chassis.vendor: HUAWEI dmi.chassis.version: M1340 dmi.ec.firmware.release: 1.41 dmi.modalias: dmi:bvnHUAWEI:bvr1.41:bd02/21/2022:br1.41:efr1.41:svnHUAWEI:pnBOHB-WAX9:pvrM1340:rvnHUAWEI:rnBOHB-WAX9-PCB-B2:rvrM1340:cvnHUAWEI:ct10:cvrM1340:skuC100: dmi.product.family: MateBook D dmi.product.name: BOHB-WAX9 dmi.product.sku: C100 dmi.product.version: M1340 dmi.sys.vendor: HUAWEI mtime.conffile..etc.modprobe.d.alsa-base.conf: 2022-06-04T20:59:26.778687 ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy wayland-session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1977685 Title: sound card Everest ESSX8336 not supported Status in alsa-driver package in Ubuntu: New Bug description: I work with Ubuntu 22.04 but the Everest semiconductor Co Ltd ESSX8336\1 sound card is not recognized. On the web a lot of people have the same problem. It's an annoying problem. Could you please help us to solve this problem. I have a Huawei Matebook D15 series Matebook D 15 (2021) i3 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: francois852 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jun 5 15:44:25 2022 InstallationDate: Installed on 2022-04-22 (43 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/21/2022 dmi.bios.release: 1.41 dmi.bios.vendor: HUAWEI dmi.bios.version: 1.41 dmi.board.asset.tag: NULL dmi.board.name: BOHB-WAX9-PCB-B2 dmi.board.vendor: HUAWEI dmi.board.version: M1340 dmi.chassis.asset.tag: NULL dmi.chassis.type: 10 dmi.chassis.vendor: HUAWEI dmi.chassis.version: M1340 dmi.ec.firmware.release: 1.41 dmi.modalias: dmi:bvnHUAWEI:bvr1.41:bd02/21/2022:br1.41:efr1.41:svnHUAWEI:pnBOHB-WAX9:pvrM1340:rvnHUAWEI:rnBOHB-WAX9-PCB-B2:rvrM1340:cvnHUAWEI:ct10:cvrM1340:skuC100: dmi.product.family: MateBook D dmi.product.name: BOHB-WAX9 dmi.product.sku: C100 dmi.product.version: M1340 dmi.sys.vendor: HUAWEI mtime.conffile..etc.modprobe.d.alsa-base.conf: 2022-06-04T20:59:26.778687 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1977685/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958267] Re: wpa can't connect to servers using TLS 1.1 or older
This bug was fixed in the package wpa - 2:2.10-9ubuntu1 --- wpa (2:2.10-9ubuntu1) kinetic; urgency=medium * debian/patches/lower_security_level_for_tls_1.patch: - set the OpenSSL security level to 0 if that is the only option to continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed in wpa_supplicant default configuration and OpenSSL 3.0 with the constraint on MD5-SHA1 use. Patch proposed by Jouni Malinen on the upstream mailinglist (lp: #1958267) -- Sebastien Bacher Tue, 31 May 2022 16:03:29 +0200 ** Changed in: wpa (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1958267 Title: wpa can't connect to servers using TLS 1.1 or older Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Jammy: Confirmed Status in wpa package in Debian: New Bug description: wpa built with in openssl3 fails to connect to TLS 1.1 or lower server those uses MD5-SHA1 as digest in its signature algorithm which no longer meets OpenSSL default level of security of 80 bits http://lists.infradead.org/pipermail/hostap/2022-May/040563.html Workaround are described in #22 and #36 by basically using CipherString = DEFAULT@SECLEVEL=0 which lowers the security level --- With the current jammy version of wpasupplicant (2:2.10-1), I cannot connect to the WPA Enterprise network eduroam, which is used by Universities worldwide. I get a "Connection failed" message or a request to re-enter the password. - I've re-tried the credentials: no fix ;-) - Tried a 21.10 live session on the same machine: works fine! - Manually downgraded wpasupplicant to the impish version (2:2.9.0-21build1): connected normally. - Upgraded wpasupplicant to the latest version: fails to connect again. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: wpasupplicant 2:2.10-1 ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12 Uname: Linux 5.15.0-17-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu75 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Jan 18 09:56:23 2022 InstallationDate: Installed on 2021-11-30 (48 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977683] Re: Lubuntu error has_option: command not found / no ssh-agent after updating to 22.04
Thank you for taking the time to report this bug and helping to make Ubuntu better. Lubuntu has used sddm for all LXQt releases (ie. since Lubuntu 18.10), and the upgrade from an release that used lightdm/LXDE is unsupported due to breakage as was warned about in documentation, eg. https://lubuntu.me/focal-2-released/ "Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install." The error you are describing is a user-created issue by using unsupported upgrade procedures that were documented as creating issues later, and this is warned about breakage. The fresh install would have prevented this. As such I've marked this bug report as "opinion". If you believe I'm in error, please leave a comment explaining why and the bug report can then be returned to "New" (you may find it'll then be marked as "Won't Fix") ** Changed in: lightdm (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1977683 Title: Lubuntu error has_option: command not found / no ssh-agent after updating to 22.04 Status in lightdm package in Ubuntu: Opinion Bug description: Hi, I have updated several machines from Lubuntu 20.04 to Lubuntu 22.04 with do-release-update -d On all but one machine this worked well, but one machine, that formerly worked without problems, now has no ssh-agent running after login, and the ~/.xsession-errors shows several xsession files to fail for the same reason: /etc/X11/Xsession.d/30x11-common_xresources: Zeile 16: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/75dbus_dbus-launch: Zeile 9: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/90x11-common_ssh-agent: Zeile 9: has_option: Befehl nicht gefunden (german for: has_option: command not found) Formerly mentioned in bug #1922414 (marked as solved) and its duplicate #1940779 , but it isn't solved. That's why there is no ssh-agent. I have done some debugging to find, why it works on all but one of my machines, and what's the reason. Reason: has_option is not a command, but a shell function defined in /etc/X11/Xsession On the good machines, the display manager is sddm, which seems to do the job well. The machine, that fails, is somewhat older and had formerly 18.04 running and been updated to 20.04 then. It runs the display manager lightdm. That's the problem: lightdm runs /usr/bin/lxqt-session and /usr/bin/lxqt-session directly opens and executes the scripts in /etc/X11/Xsession.d without running /etc/X11/Xsession. Therefore, the shell function has_optionis never defined, but used in the scripts, which do fail then. Therefore, either lxqt-session needs to be made compatible with /etc/X11/Xsession, or the upgrade-procedure 20.04 to 22.04 must replace lightdm by sddm. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: lightdm 1.30.0-0ubuntu5 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: LXQt Date: Sun Jun 5 14:48:42 2022 InstallationDate: Installed on 2018-04-28 (1498 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: lightdm UpgradeStatus: Upgraded to jammy on 2022-06-04 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1977683/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977676] Re: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
Thank you for taking the time to report this bug and helping to make Ubuntu better. Bug reporting is mostly about finding & fixing problems thus preventing future users from hitting the same bug. I suspect a Support site would be more appropriate, eg. https://answers.launchpad.net/ubuntu. You can also find help with your problem in the support forum of your local Ubuntu community http://loco.ubuntu.com/ or asking at https://askubuntu.com or https://ubuntuforums.org, or for more support options please look at https://discourse.ubuntu.com/t/community-support/709 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1977676 Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: Invalid Bug description: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.13.0-44.49~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 AptOrdering: kmod:amd64: Install libkmod2:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Jun 5 08:55:45 2022 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-24 (527 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.8 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1977676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977683] [NEW] Lubuntu error has_option: command not found / no ssh-agent after updating to 22.04
Public bug reported: Hi, I have updated several machines from Lubuntu 20.04 to Lubuntu 22.04 with do-release-update -d On all but one machine this worked well, but one machine, that formerly worked without problems, now has no ssh-agent running after login, and the ~/.xsession-errors shows several xsession files to fail for the same reason: /etc/X11/Xsession.d/30x11-common_xresources: Zeile 16: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/75dbus_dbus-launch: Zeile 9: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/90x11-common_ssh-agent: Zeile 9: has_option: Befehl nicht gefunden (german for: has_option: command not found) Formerly mentioned in bug #1922414 (marked as solved) and its duplicate #1940779 , but it isn't solved. That's why there is no ssh-agent. I have done some debugging to find, why it works on all but one of my machines, and what's the reason. Reason: has_option is not a command, but a shell function defined in /etc/X11/Xsession On the good machines, the display manager is sddm, which seems to do the job well. The machine, that fails, is somewhat older and had formerly 18.04 running and been updated to 20.04 then. It runs the display manager lightdm. That's the problem: lightdm runs /usr/bin/lxqt-session and /usr/bin/lxqt-session directly opens and executes the scripts in /etc/X11/Xsession.d without running /etc/X11/Xsession. Therefore, the shell function has_optionis never defined, but used in the scripts, which do fail then. Therefore, either lxqt-session needs to be made compatible with /etc/X11/Xsession, or the upgrade-procedure 20.04 to 22.04 must replace lightdm by sddm. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: lightdm 1.30.0-0ubuntu5 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: LXQt Date: Sun Jun 5 14:48:42 2022 InstallationDate: Installed on 2018-04-28 (1498 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: lightdm UpgradeStatus: Upgraded to jammy on 2022-06-04 (0 days ago) ** Affects: lightdm (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1977683 Title: Lubuntu error has_option: command not found / no ssh-agent after updating to 22.04 Status in lightdm package in Ubuntu: New Bug description: Hi, I have updated several machines from Lubuntu 20.04 to Lubuntu 22.04 with do-release-update -d On all but one machine this worked well, but one machine, that formerly worked without problems, now has no ssh-agent running after login, and the ~/.xsession-errors shows several xsession files to fail for the same reason: /etc/X11/Xsession.d/30x11-common_xresources: Zeile 16: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/75dbus_dbus-launch: Zeile 9: has_option: Befehl nicht gefunden /etc/X11/Xsession.d/90x11-common_ssh-agent: Zeile 9: has_option: Befehl nicht gefunden (german for: has_option: command not found) Formerly mentioned in bug #1922414 (marked as solved) and its duplicate #1940779 , but it isn't solved. That's why there is no ssh-agent. I have done some debugging to find, why it works on all but one of my machines, and what's the reason. Reason: has_option is not a command, but a shell function defined in /etc/X11/Xsession On the good machines, the display manager is sddm, which seems to do the job well. The machine, that fails, is somewhat older and had formerly 18.04 running and been updated to 20.04 then. It runs the display manager lightdm. That's the problem: lightdm runs /usr/bin/lxqt-session and /usr/bin/lxqt-session directly opens and executes the scripts in /etc/X11/Xsession.d without running /etc/X11/Xsession. Therefore, the shell function has_optionis never defined, but used in the scripts, which do fail then. Therefore, either lxqt-session needs to be made compatible with /etc/X11/Xsession, or the upgrade-procedure 20.04 to 22.04 must replace lightdm by sddm. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: lightdm 1.30.0-0ubuntu5 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: LXQt Date: Sun Jun 5 14:48:42 2022 InstallationDate: Installed on 2018-04-28 (1498 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" -
[Touch-packages] [Bug 1976619] Re: Version 7.81 breaks support for multi-line header
This bug was fixed in the package curl - 7.83.1-1ubuntu1
---
curl (7.83.1-1ubuntu1) kinetic; urgency=medium
* Apply upstream patch to fix multi-line header support (LP: #1976619)
-- Olivier Gayot Thu, 02 Jun 2022
13:44:50 +0200
** Changed in: curl (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/1976619
Title:
Version 7.81 breaks support for multi-line header
Status in curl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
New
Status in curl package in Debian:
New
Bug description:
In curl 7.81, the support of multi-line headers is broken.
This causes regressions in python-tornado:
```
self.stop()
timeout_handle = self.add_timeout(self.time() + timeout,
timeout_callback)
self.start()
if timeout is not None:
self.remove_timeout(timeout_handle)
assert future_cell[0] is not None
if future_cell[0].cancelled() or not future_cell[0].done():
raise TimeoutError("Operation timed out after %s seconds" %
timeout)
> return future_cell[0].result()
E tornado.curl_httpclient.CurlError: HTTP 599: Header without colon
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1976619/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958019]
Yeah, both the speaker and headphones work fine with correct channel. And still work after resuming from suspend/hibernate. Also fine after hotplug events, whatever it is playing or not. Thanks for your patch a lot! (In reply to Cameron Berkenpas from comment #627) > Great! > > Some probably silly questions: > 1) Do both speakers work? Do you get left channel sound out of the left > speaker and right channel sound out of the right speaker? > > 2) After resuming from suspend/hibernate, does your sound still work? > > 3) What if you insert headphones and remove them? Does sound still work? > Try removing the headphones both while sound is not playing and while > it's not. > > Given that this old quirk works for your laptop, I think all of the > above will be fine and I can work toward getting this submitted. > > > On 6/3/2022 5:34 PM, bugzilla-dae...@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #626 from Songine (donglingluoy...@gmail.com) --- > > (In reply to Cameron Berkenpas from comment #625) > >> Did you test this yourself? > >> > >> On 6/3/22 00:11, bugzilla-dae...@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> Songine (donglingluoy...@gmail.com) changed: > >>> > >>> What|Removed |Added > >>> > >> > > >>>CC| > >>>|donglingluoy...@gmail.com > >>> > >>> --- Comment #624 from Songine (donglingluoy...@gmail.com) --- > >>> (In reply to Cameron Berkenpas from comment #429) > Created attachment 298789 [details] > linux-legion-sound-0.0.13.patch > > auto mute is now properly disabled as per Takashi's suggestion. > > This patch is against the latest Linus tree, but applies against 5.14.3 > >> just > fine. > > This patch includes the presumptive commit message and credit given to > various people. > > Going through the Linux commit log, it seems full names and email > >> addresses > aren't needed, so I have a thank you list in the patch with the > following: > Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle > > If you want to be mentioned (or if you know of someone who you think > that > should be included), please let me know! > > Here's a link to the patch submission: > > >> > https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. > html > >>> Hello, there is a device could use the patch, could you help me add it to > >> the > >>> patch file? > >>> > >>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > >>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > >>> > > Yes, tested, and I am enjoging my speaker now.�[U+1F603]� > > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install)
[Touch-packages] [Bug 1958019]
Great! Some probably silly questions: 1) Do both speakers work? Do you get left channel sound out of the left speaker and right channel sound out of the right speaker? 2) After resuming from suspend/hibernate, does your sound still work? 3) What if you insert headphones and remove them? Does sound still work? Try removing the headphones both while sound is not playing and while it's not. Given that this old quirk works for your laptop, I think all of the above will be fine and I can work toward getting this submitted. On 6/3/2022 5:34 PM, bugzilla-dae...@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #626 from Songine (donglingluoy...@gmail.com) --- > (In reply to Cameron Berkenpas from comment #625) >> Did you test this yourself? >> >> On 6/3/22 00:11, bugzilla-dae...@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Songine (donglingluoy...@gmail.com) changed: >>> >>> What|Removed |Added >>> >> >>>CC| >>>|donglingluoy...@gmail.com >>> >>> --- Comment #624 from Songine (donglingluoy...@gmail.com) --- >>> (In reply to Cameron Berkenpas from comment #429) Created attachment 298789 [details] linux-legion-sound-0.0.13.patch auto mute is now properly disabled as per Takashi's suggestion. This patch is against the latest Linus tree, but applies against 5.14.3 >> just fine. This patch includes the presumptive commit message and credit given to various people. Going through the Linux commit log, it seems full names and email >> addresses aren't needed, so I have a thank you list in the patch with the following: Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle If you want to be mentioned (or if you know of someone who you think that should be included), please let me know! Here's a link to the patch submission: >> https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. html >>> Hello, there is a device could use the patch, could you help me add it to >> the >>> patch file? >>> >>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", >>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >>> > Yes, tested, and I am enjoging my speaker now.�[U+1F603]� > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2021 dmi.bios.release: 1.49 dmi.bios.vendor: LENOVO dmi.bios.version: GKCN49WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0R32862 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion 7 16ACHg6 dmi.ec.firmware.release: 1.49 dmi.modalias:
[Touch-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
[Touch-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
[Touch-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 Ubuntu Touch seeded 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977676] Re: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
Thank you for taking the time to report this bug and helping to make Ubuntu better. Reviewing your dmesg attachment in this bug report it seems that there is a problem with your hardware. I recommend performing a back up and then investigating the situation. Measures you might take include checking cable connections and using software tools to investigate the health of your hardware. In the event that is is not in fact an error with your hardware please set the bug's status back to New. Thanks and good luck! [This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.] ** Tags added: hardware-error ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Low ** Changed in: initramfs-tools (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1977676 Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: Invalid Bug description: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.13.0-44.49~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 AptOrdering: kmod:amd64: Install libkmod2:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Jun 5 08:55:45 2022 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-24 (527 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.8 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1977676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977677] [NEW] software-properties-qt selects ports mirror in amd64 Kubuntu
Public bug reported: Hello, I'm a user who installed Kubuntu 22.04 today, and trying to use software-properties-qt package at Konsole(command line). When I try to change software sources to the mirror that includes Ubuntu Ports mirror service, software-properties-qt package change APT Sources files to use /ubuntu-ports/ instead /ubuntu/. I experienced this situation with three South Korea mirrors that also have ubuntu-ports mirroring service, "ftp.harukasan.org" / "mirror.misakamikoto.network" / "ftp.lanet.kr". However, my system is not using Ubuntu Ports - because it uses AMD64 processor(10th generation Intel Core i5-1035G7) - so if who tries `apt update` then get HTTP 404 errors from mirror. Because of this, user need to remove `-ports` with `apt edit-sources` manually. System Information: - OS: Kubuntu 22.04 - KDE Plasma Version: 5.24.4 - KDE Framework Version: 5.92.0 - Qt Version: 5.15.3 - Kernel Version: 5.15.0-35-generic (64Bit) - Graphic Platform: X11 - software-properties-qt version: 0.99.22.1 - python3-software-properties version: 0.99.22.1 - software-properties-common version: 0.99.22.1 - CPU: 10th generation Intel Core i5-1035G7 - RAM: 16GB DDR4 3200MHz (Dual-Channel) - Graphics: Integrated Intel Iris Plus Graphics ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1977677 Title: software-properties-qt selects ports mirror in amd64 Kubuntu Status in software-properties package in Ubuntu: New Bug description: Hello, I'm a user who installed Kubuntu 22.04 today, and trying to use software-properties-qt package at Konsole(command line). When I try to change software sources to the mirror that includes Ubuntu Ports mirror service, software-properties-qt package change APT Sources files to use /ubuntu-ports/ instead /ubuntu/. I experienced this situation with three South Korea mirrors that also have ubuntu-ports mirroring service, "ftp.harukasan.org" / "mirror.misakamikoto.network" / "ftp.lanet.kr". However, my system is not using Ubuntu Ports - because it uses AMD64 processor(10th generation Intel Core i5-1035G7) - so if who tries `apt update` then get HTTP 404 errors from mirror. Because of this, user need to remove `-ports` with `apt edit-sources` manually. System Information: - OS: Kubuntu 22.04 - KDE Plasma Version: 5.24.4 - KDE Framework Version: 5.92.0 - Qt Version: 5.15.3 - Kernel Version: 5.15.0-35-generic (64Bit) - Graphic Platform: X11 - software-properties-qt version: 0.99.22.1 - python3-software-properties version: 0.99.22.1 - software-properties-common version: 0.99.22.1 - CPU: 10th generation Intel Core i5-1035G7 - RAM: 16GB DDR4 3200MHz (Dual-Channel) - Graphics: Integrated Intel Iris Plus Graphics To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1977677/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977676] [NEW] package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status
Public bug reported: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.13.0-44.49~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 AptOrdering: kmod:amd64: Install libkmod2:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Jun 5 08:55:45 2022 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-24 (527 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.8 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal need-duplicate-check -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1977676 Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.13.0-44.49~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 AptOrdering: kmod:amd64: Install libkmod2:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Jun 5 08:55:45 2022 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-24 (527 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.8 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1977676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1862764] Re: add-apt-repository should use signed-by
My goal would be to switch to deb822 sources for this with the key embedded in the .sources file. We're still missing the ability to edit those files graphically however, that needs to be implemented first. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1862764 Title: add-apt-repository should use signed-by Status in python-apt package in Ubuntu: Confirmed Status in software-properties package in Ubuntu: Confirmed Status in software-properties package in Debian: New Bug description: add-apt-repository should use signed-by apt sources.list syntax supports limiting which keys are used to sign a given repo. It would be nice for add-apt-repository to import the key somewhere else but trusted.gpg.d and then specify path to it, using the "signed- by" field. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: software-properties-common 0.98.6 ProcVersionSignature: Ubuntu 5.4.0-1002.4-oem 5.4.8 Uname: Linux 5.4.0-1002-oem x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Feb 11 12:01:49 2020 InstallationDate: Installed on 2016-01-26 (1477 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: software-properties UpgradeStatus: Upgraded to focal on 2019-01-15 (391 days ago) modified.conffile..etc.default.apport: [modified] mtime.conffile..etc.default.apport: 2020-01-10T16:24:15.968394 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1862764/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
