[Touch-packages] [Bug 1862764] Re: add-apt-repository should use signed-by
I started using Ubuntu 22.04 and this issue started to occour. The 'add-apt-repository' command adds the gpg key of the PPA repository in the trusted.gpg file (/etc/apt/trusted.gpg) As commented above, the PPA repositories are not being included in the sources.list file (/etc/apt/sources.list) or in the directory /etc/apt/sources.list.d/ with the parameter [signed-by=] Workaround: While the fix doesn't come, the way is to adapt the repository in this way: 1- $ sudo add-apt-repository ppa:author/project 2- $ apt-key list 3- $ gpg --export | sudo tee /etc/apt/trusted.gpg.d/.gpg 4- $ sudo nano /etc/apt/sources.list.d/repository-name.list 5- Find & Replace: deb http://ppa.launchpad.net/author/project/ubuntu jammy main by deb [signed-by=/etc/apt/trusted.gpg.d/.gpg http://ppa.launchpad.net/author/project/ubuntu jammy main 6- Save the changes and run 'sudo apt update' again -- 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
[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. + ip6.privacy=0 for the connection. Then it would not generate temporary + addresses and use the DHCPv6 address as the source for outgoing traffic. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 - address would be used to connect to the outside world. + address would be used to connect to the outside world and be echoed + back. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change in IPv6 source address selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of 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
[Touch-packages] [Bug 1977619] Re: NetworkManager 1.36.6 orders IPv6 addresses incorrectly
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: network-manager (Ubuntu) Status: New => Confirmed -- 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. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change 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 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 1933880] Re: systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it
Can confirm that removing the .service files in /etc/systemd/system/systemd-suspend.service.requires works. The reason this occurred to me is because i switched GPU from nvidia to AMD, and some programs thought I have nvenc (because the library is installed) when i don't, which necessitates the removal of the nvidia- driver packages. This seem like an issue with one of the nvidia package's postrm debian package scripts as opposed to systemd, tho. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1933880 Title: systemd-logind crash when suspend with nvidia-suspend.service masked, bringing session down with it Status in nvidia-graphics-drivers-465 package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Run `sudo apt install nvidia-driver-465`. Then, without a need for a restart, run `sudo apt autoremove nvidia-driver-465`. 2. Leaving the terminal open, suspend the machine. Expected behavior: the machine suspend successfully and can be woken up successfully. Actual behavior: the machine doesn't suspend. It either: - hang with no respond other than SysRq+REISUB (or maybe network, but I didn't test), or - return you back to the login screen. Upon logging in, you'll notice that the terminal you opened is gone. Upon further inspection (on a session that doesn't hang), it's been found that X server died with: Fatal server error: [66.422] (EE) systemd-logind disappeared (stopped/restarted?) And checking journal for systemd-logind log, it said: Error during inhibitor-delayed operation (already returned success to client): Unit nvidia-suspend.service is masked. before the new process takes it place. The system is Ubuntu 20.04, X.org session. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.7 ProcVersionSignature: Ubuntu 5.11.0-22.23~20.04.1-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Jun 29 03:34:00 2021 InstallationDate: Installed on 2021-03-15 (105 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: LENOVO 82B5 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=th_TH.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=UUID=06f2a676-a62c-443a-8bc8-4e0eda4600f4 ro log_buf_len=2M quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2021 dmi.bios.release: 1.31 dmi.bios.vendor: LENOVO dmi.bios.version: EUCN31WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55756 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo Legion 5 15ARH05 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrEUCN31WW:bd01/01/2021:br1.31:efr1.31:svnLENOVO:pn82B5:pvrLenovoLegion515ARH05:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55756WIN:cvnLENOVO:ct10:cvrLenovoLegion515ARH05: dmi.product.family: Legion 5 15ARH05 dmi.product.name: 82B5 dmi.product.sku: LENOVO_MT_82B5_BU_idea_FM_Legion 5 15ARH05 dmi.product.version: Lenovo Legion 5 15ARH05 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-465/+bug/1933880/+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 1955704] Re: systemd/plymouth preventing reboot/shutdown
Hi [~phm2f1alcw69] is this possibly related to #1977652 ? Depends on: - your version of systemd / ubuntu (I don't see any versions in this report) - whether you also saw items looped in the logs (journald -b -1 | tail) Cheers, Walter -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955704 Title: systemd/plymouth preventing reboot/shutdown Status in systemd package in Ubuntu: New Bug description: Plymouth seems to be busy with trying to show a "Halt" and also a "Reboot" screen during shutdown, and in trying to do so preventing the actual shutdown procedure to succeed. It even continues to do so after forcing the shutdown/reboot procedure as can be seen in the attached screenshot. Systemd then continues the show with waiting for an obscure kwin process, which ceased to exist long before. Of course, systemctl doesn't work at this stage any more either, so log files are useless. p.s. after giving the two processes systemd & plymouth several minutes to finish what they were claiming to do, I had tp pull the plug to end this farce. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955704/+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 1977649] Re: my system is not showing me 1080p resolution
** Package changed: ubuntu => xorg (Ubuntu) -- 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/1977649 Title: my system is not showing me 1080p resolution Status in xorg package in Ubuntu: New Bug description: After ubuntu 20 install I am not able to increase my screen resolution. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 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 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sat Jun 4 19:16:39 2022 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu GraphicsCard: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller [8086:041e] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd 4th Generation Core Processor Family Integrated Graphics Controller [1458:d000] InstallationDate: Installed on 2022-06-04 (0 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) MachineType: Gigabyte Technology Co., Ltd. H81M-S1 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-44-generic root=UUID=fc58eb01-ce48-4d0e-ac05-443d37948ed0 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/17/2014 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: FC dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: H81M-S1 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrFC:bd01/17/2014:br4.6:svnGigabyteTechnologyCo.,Ltd.:pnH81M-S1:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnH81M-S1:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: H81M-S1 dmi.product.sku: To be filled by O.E.M. dmi.product.version: To be filled by O.E.M. dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1977649/+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 1977652] [NEW] systemd loops trying to start systemd-ask-password-plymouth
Public bug reported: Short story: - after boot - when a systemd service wants a password - systemd-ask-password is invoked - systemd-ask-password-plymouth.path is reached - systemd-ask-password-plymouth.service is started Except: - the conditions for the latter are (apparently) not met End result: - 40.000x "Condition check resulted in Forward Password Requests to Plymouth being skipped." - 1.5 minutes of 100% cpu usage AFFECTED VERSION systemd 249.11-0ubuntu3.1 on Ubuntu/Jammy 22.04 HOW TO REPRODUCE If I leave the `systemd-ask-password-plymouth.path` unmasked/enabled and reboot. OpenVPN (calling systemd-ask-password) will trigger the condition. This causes high CPU usage for 1.5 minutes. It looks like /run/plymouth/pid exists (for the .path file) at first, when that is invoked, but then the resultant target (the .service file) checks again, and finds that it is gone. Manually reproducing: # ls /run/systemd/ask-password ask.5hW6rb sck.79cfe1203518610 # mkdir /run/plymouth/pid # systemctl start systemd-ask-password-plymouth.service systemd-ask-password-plymouth.path # systemctl show --value --property=MainPID systemd-ask-password-plymouth.service 24777 # rmdir /run/plymouth/pid ; kill 24777 Result: systemd going into a loop. Stop the loop with: # systemctl stop systemd-ask-password-plymouth.path ANALYSIS It looks like this: https://github.com/systemd/systemd/issues/21025 which is fixed by: https://github.com/systemd/systemd/pull/21030 Alternative bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1919538 Systemd's own analysis of the situation: # systemd-analyze critical-chain systemd-ask-password-plymouth.service ... systemd-ask-password-plymouth.service @1min 35.823s └─systemd-ask-password-plymouth.path @593ms └─plymouth-start.service @571ms +21ms └─systemd-udevd.service @450ms +119ms └─systemd-tmpfiles-setup-dev.service @429ms +18ms └─systemd-sysusers.service @382ms +46ms └─systemd-remount-fs.service @353ms +22ms └─systemd-journald.socket @318ms └─system.slice @264ms └─-.slice @264ms --- WORKAROUNDS --- This works as long as you don't need the plymouth-ask-password: # systemctl disable systemd-ask-password-plymouth.path # systemctl mask systemd-ask-password-plymouth.path Could you get the relevant patches from upstream sorted in Jammy? Thanks! Walter Doekes OSSO B.V. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1977652 Title: systemd loops trying to start systemd-ask-password-plymouth Status in systemd package in Ubuntu: New Bug description: Short story: - after boot - when a systemd service wants a password - systemd-ask-password is invoked - systemd-ask-password-plymouth.path is reached - systemd-ask-password-plymouth.service is started Except: - the conditions for the latter are (apparently) not met End result: - 40.000x "Condition check resulted in Forward Password Requests to Plymouth being skipped." - 1.5 minutes of 100% cpu usage AFFECTED VERSION systemd 249.11-0ubuntu3.1 on Ubuntu/Jammy 22.04 HOW TO REPRODUCE If I leave the `systemd-ask-password-plymouth.path` unmasked/enabled and reboot. OpenVPN (calling systemd-ask-password) will trigger the condition. This causes high CPU usage for 1.5 minutes. It looks like /run/plymouth/pid exists (for the .path file) at first, when that is invoked, but then the resultant target (the .service file) checks again, and finds that it is gone. Manually reproducing: # ls /run/systemd/ask-password ask.5hW6rb sck.79cfe1203518610 # mkdir /run/plymouth/pid # systemctl start systemd-ask-password-plymouth.service systemd-ask-password-plymouth.path # systemctl show --value --property=MainPID systemd-ask-password-plymouth.service 24777 # rmdir /run/plymouth/pid ; kill 24777 Result: systemd going into a loop. Stop the loop with: # systemctl stop systemd-ask-password-plymouth.path ANALYSIS It looks like this: https://github.com/systemd/systemd/issues/21025 which is fixed by: https://github.com/systemd/systemd/pull/21030 Alternative bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1919538 Systemd's own analysis of the situation: # systemd-analyze critical-chain systemd-ask-password-plymouth.service ... systemd-ask-password-plymouth.service @1min 35.823s └─systemd-ask-password-plymouth.path @593ms └─plymouth-start.service @571ms +21ms └─systemd-udevd.service @450ms +119ms └─systemd-tmpfiles-setup-dev.service @429ms
[Touch-packages] [Bug 1977649] [NEW] my system is not showing me 1080p resolution
You have been subscribed to a public bug: After ubuntu 20 install I am not able to increase my screen resolution. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 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 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sat Jun 4 19:16:39 2022 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu GraphicsCard: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller [8086:041e] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd 4th Generation Core Processor Family Integrated Graphics Controller [1458:d000] InstallationDate: Installed on 2022-06-04 (0 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) MachineType: Gigabyte Technology Co., Ltd. H81M-S1 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-44-generic root=UUID=fc58eb01-ce48-4d0e-ac05-443d37948ed0 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/17/2014 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: FC dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: H81M-S1 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrFC:bd01/17/2014:br4.6:svnGigabyteTechnologyCo.,Ltd.:pnH81M-S1:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnH81M-S1:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: H81M-S1 dmi.product.sku: To be filled by O.E.M. dmi.product.version: To be filled by O.E.M. dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal third-party-packages ubuntu -- my system is not showing me 1080p resolution https://bugs.launchpad.net/bugs/1977649 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. -- 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 1977648] [NEW] GLX is rendered by Intel GPU only in Wayland
Public bug reported: I'm using Nvidia driver and PRIME profile is set to performance, however in Wayland only, GLX is rendered by Intel GPU and can't have Nvidia as default renderer. This is a problem because not all OpenGL applications can work with XWayland or by setting the ENV variables to use Nvidia. In Xorg Nvidia can be the default renderer with the same configuration. $ prime-select query nvidia $ glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49) Version: 22.0.1 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.1 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.1 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.0.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-shell 42.1-0ubuntu0.1 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Sat Jun 4 15:15:50 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-02-03 (120 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) RelatedPackageVersions: mutter-common 42.1-0ubuntu1 SourcePackage: gnome-shell UpgradeStatus: Upgraded to jammy on 2022-04-21 (43 days ago) ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ** Also affects: wayland (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1977648 Title: GLX is rendered by Intel GPU only in Wayland Status in gnome-shell package in Ubuntu: New Status in wayland package in Ubuntu: New Bug description: I'm using Nvidia driver and PRIME profile is set to performance, however in Wayland only, GLX is rendered by Intel GPU and can't have Nvidia as default renderer. This is a problem because not all OpenGL applications can work with XWayland or by setting the ENV variables to use Nvidia. In Xorg Nvidia can be the default renderer with the same configuration. $ prime-select query nvidia $ glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49) Version: 22.0.1 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.1 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.1 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.0.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-shell 42.1-0ubuntu0.1 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Sat Jun 4 15:15:50 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-02-03 (120 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) RelatedPackageVersions: mutter-common 42.1-0ubuntu1 SourcePackage: gnome-shell UpgradeStatus: Upgraded to jammy on
[Touch-packages] [Bug 1977647] [NEW] package linux-firmware 20220329.git681281e4-0ubuntu3.2 failed to install/upgrade: installed linux-firmware package post-installation script subprocess returned err
Public bug reported: I didn't perform any action to get this crash. ProblemType: Package DistroRelease: Ubuntu 22.04 Package: linux-firmware 20220329.git681281e4-0ubuntu3.2 ProcVersionSignature: Ubuntu 5.15.0-33.34-lowlatency 5.15.30 Uname: Linux 5.15.0-33-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: marqrdt 676730 F pulseaudio /dev/snd/controlC0: marqrdt 676730 F pulseaudio /dev/snd/controlC1: marqrdt 676730 F pulseaudio CasperMD5CheckResult: pass Date: Tue May 31 11:25:55 2022 Dependencies: firmware-sof-signed 2.0-1ubuntu3 ErrorMessage: installed linux-firmware package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-07-09 (330 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Gigabyte Technology Co., Ltd. X570 AORUS PRO WIFI PackageArchitecture: all ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.15.0-33-lowlatency root=/dev/mapper/vgubuntu-root ro threadirqs quiet splash vt.handoff=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. Python3Details: /usr/bin/python3.10, Python 3.10.4, python3-minimal, 3.10.4-0ubuntu2 PythonDetails: /usr/bin/python3.10, Python 3.10.4, python-is-python3, 3.9.2-2 RelatedPackageVersions: grub-pc 2.06-2ubuntu7 SourcePackage: initramfs-tools Title: package linux-firmware 20220329.git681281e4-0ubuntu3.2 failed to install/upgrade: installed linux-firmware package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to jammy on 2022-04-21 (43 days ago) dmi.bios.date: 06/13/2019 dmi.bios.release: 5.14 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F3 dmi.board.asset.tag: Default string dmi.board.name: X570 AORUS PRO WIFI dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF3:bd06/13/2019:br5.14:svnGigabyteTechnologyCo.,Ltd.:pnX570AORUSPROWIFI:pvr-CF:rvnGigabyteTechnologyCo.,Ltd.:rnX570AORUSPROWIFI:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring: dmi.product.family: Default string dmi.product.name: X570 AORUS PRO WIFI dmi.product.sku: Default string dmi.product.version: -CF dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package jammy -- 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/1977647 Title: package linux-firmware 20220329.git681281e4-0ubuntu3.2 failed to install/upgrade: installed linux-firmware package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: I didn't perform any action to get this crash. ProblemType: Package DistroRelease: Ubuntu 22.04 Package: linux-firmware 20220329.git681281e4-0ubuntu3.2 ProcVersionSignature: Ubuntu 5.15.0-33.34-lowlatency 5.15.30 Uname: Linux 5.15.0-33-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: marqrdt 676730 F pulseaudio /dev/snd/controlC0: marqrdt 676730 F pulseaudio /dev/snd/controlC1: marqrdt 676730 F pulseaudio CasperMD5CheckResult: pass Date: Tue May 31 11:25:55 2022 Dependencies: firmware-sof-signed 2.0-1ubuntu3 ErrorMessage: installed linux-firmware package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-07-09 (330 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Gigabyte Technology Co., Ltd. X570 AORUS PRO WIFI PackageArchitecture: all ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.15.0-33-lowlatency root=/dev/mapper/vgubuntu-root ro threadirqs quiet splash vt.handoff=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. Python3Details: /usr/bin/python3.10, Python 3.10.4, python3-minimal, 3.10.4-0ubuntu2 PythonDetails: /usr/bin/python3.10, Python 3.10.4, python-is-python3, 3.9.2-2 RelatedPackageVersions: grub-pc 2.06-2ubuntu7 SourcePackage: initramfs-tools Title: package linux-firmware 20220329.git681281e4-0ubuntu3.2 failed to install/upgrade: installed linux-firmware
[Touch-packages] [Bug 1974428] Re: Update to the current 1.36 stable version
@seb128 I have created a new bug report with links to the upstream commits. The core of the issue is that IPv6 addresses are now being added in the wrong order, so the kernel prefers SLAAC addresses over DHCPv6 addresses, which should be the other way around. As this is a breaking change in source-based IPv6 routing in an LTS release, I think the impact is severe. In my opinion, this update should never have reached stable, especially because this bug is known upstream and fixed in a later version. I'm already quite stressed how this will turn out at work after the weekend. We use source-based ACL's on all of our firewalls, giving static DHCPv6 leases to our client devices. Now all of a sudden those addresses are no longer being used for outgoing traffic, but instead the non-controllable SLAAC-addresses are. This will lock everyone out of all servers. The only way to get the proper addresses to be preferred again seems to be to disable SLAAC on the router, because any local setting in NetworkManager no longer works. I can disable SLAAC without issues at home, because everything is 100% Ubuntu and Debian there. But in environments with other OS'es that don't support DHCPv6 (like Android), disabling SLAAC will break IPv6 on all such devices. Moreover, not everybody controls their own routers, so this really isn't much of a solution. Other options would be to downgrade and apt-mark hold network-manager on all Ubuntu 22.04 devices, or to completely change server firewall infrastructure by whitelisting prefixes. As you can see, none of these options sound appealing. So regarding the regression potential: it has severely regressed IPv6 handling, and definitely *not* fixed things. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1974428 Title: Update to the current 1.36 stable version Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Jammy: Fix Released Bug description: * Impact It's a stable update from upstream, the changes are listed in the NEWS https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS * Test Case Since it's an update with several fixes the testing should focus on a specific point but rather by validating that the testplan is green, https://wiki.ubuntu.com/NetworkManager/DistroTesting * Regression potential There are fixes around IPv6 handling, VPN connections and the hotspot feature, verify that those configurations are still working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/+subscriptions -- Mailing list: https://launchpad.net/~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 1977645] Re: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail
The attachment "0001-avoid-identifying-as-beta-FIXED.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1977645 Title: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail Status in gpgme1.0 package in Ubuntu: New Bug description: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary-equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1977645/+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 1977499] Re: BUG IN UBUNTU 22.10 KINETIC KUDU: Audio Does Not Work Properly And Video Playback Is Very Laggy
When i made the same dist-upgrade, Ubuntu was moving from pulseaudio to pipewire. The result was: no sound hardware detected. So into a terminal i have ran: sudo touch /usr/share/pipewire/media-session.d/with-pulseaudio systemctl --user restart pipewire-session-manager After a reboot, the sound hardware was found and set to work as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1977499 Title: BUG IN UBUNTU 22.10 KINETIC KUDU: Audio Does Not Work Properly And Video Playback Is Very Laggy Status in pulseaudio package in Ubuntu: New Bug description: I had recently upgraded from Ubuntu 22.04 LTS Jammy Jellyfish To Ubuntu 22.10 Kinetic Kudu (Development Branch) and i found 2 NEW Problems with it... 1) Audio does not work at all 2) Video playback is very laggy and not as smooth as before When i played a video,The playback was so laggy making me want to smash the screen and there was no audio at all like seriously,I am seeing this problem ever since I've upgraded to Ubuntu 22.10 Kinetic Kudu (Development Branch),Please Ubuntu Team fix this problem! ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: pulseaudio 1:15.99.1+dfsg1-1ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30 Uname: Linux 5.15.0-27-generic x86_64 ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: rasth F pipewire-media- /dev/snd/seq:rasth 1110 F pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jun 3 05:52:08 2022 InstallationDate: Installed on 2022-06-03 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha amd64 (20220602) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: pulseaudio Symptom: audio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/12/2020 dmi.bios.release: 4.6 dmi.bios.vendor: Phoenix Technologies LTD dmi.bios.version: 6.00 dmi.board.name: 440BX Desktop Reference Platform dmi.board.vendor: Intel Corporation dmi.board.version: None dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 1 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.ec.firmware.release: 0.0 dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/12/2020:br4.6:efr0.0:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku: dmi.product.name: VMware Virtual Platform dmi.product.version: None dmi.sys.vendor: VMware, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1977499/+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 1977645] Re: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail
Created PR at Debian: https://salsa.debian.org/debian/gpgme/-/merge_requests/4 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1977645 Title: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail Status in gpgme1.0 package in Ubuntu: New Bug description: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary-equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1977645/+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 1977645] [NEW] python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail
Public bug reported: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary- equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. ** Affects: gpgme1.0 (Ubuntu) Importance: Undecided Status: New ** Tags: patch ** Patch added: "0001-avoid-identifying-as-beta-FIXED.patch" https://bugs.launchpad.net/bugs/1977645/+attachment/5594802/+files/0001-avoid-identifying-as-beta-FIXED.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1977645 Title: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail Status in gpgme1.0 package in Ubuntu: New Bug description: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary-equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1977645/+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 1947588] Re: Infinite Loop in OpenSSL s_server
This bug was fixed in the package openssl - 3.0.3-5ubuntu2 --- openssl (3.0.3-5ubuntu2) kinetic; urgency=medium * d/p/Set-systemwide-default-settings-for-libssl-users: don't comment out the CipherString string to avoid an empty section. -- Simon Chopin Tue, 31 May 2022 13:02:15 +0200 ** Changed in: openssl (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: Confirmed Status in openssl source package in Impish: Confirmed Status in openssl source package in Jammy: Confirmed Bug description: [Impact] The TLS test server `openssl s_server` can very easily be led into an infinite loop if configured with incompatible settings and used via DTLS. This makes it harder to test one's TLS configuration. [Test plan] In one session: $ openssl s_server -nocert -psk 01020304 -dtls1 In parallel: $ openssl s_client -dtls1 -psk 01020304 The server session will enter an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ... etc... [Where problems could occur] The patch is fairly self-contained, so regressions should only occur in the `openssl s_server` application, and not in the libssl or libcrypto libraries. However, the patch could break said server, which might be used in e.g. autopkgtests. [Original report] Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+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 1974035] Re: openssl: Merge 3.0.3-4 from Debian unstable
This bug was fixed in the package openssl - 3.0.3-5ubuntu2 --- openssl (3.0.3-5ubuntu2) kinetic; urgency=medium * d/p/Set-systemwide-default-settings-for-libssl-users: don't comment out the CipherString string to avoid an empty section. -- Simon Chopin Tue, 31 May 2022 13:02:15 +0200 ** Changed in: openssl (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1974035 Title: openssl: Merge 3.0.3-4 from Debian unstable Status in openssl package in Ubuntu: Fix Released Bug description: The version 3.0.3-4 from Debian unstable should be merged in Kinetic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1974035/+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 1972056] Re: [openssl3] please sync openssl.cnf to ease changing security level
This bug was fixed in the package openssl - 3.0.3-5ubuntu2 --- openssl (3.0.3-5ubuntu2) kinetic; urgency=medium * d/p/Set-systemwide-default-settings-for-libssl-users: don't comment out the CipherString string to avoid an empty section. -- Simon Chopin Tue, 31 May 2022 13:02:15 +0200 ** Changed in: openssl (Ubuntu Kinetic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1972056 Title: [openssl3] please sync openssl.cnf to ease changing security level Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Confirmed Status in openssl source package in Kinetic: Fix Released Status in openssl package in Debian: Fix Released Bug description: [Impact] The OpenSSL 3.0 lead to a lot of broken setups. Some of them are regressions, but others are simply broken due to the use of outdated algorithms, such as SHA-1 signature on certificates. Changing the security level is a common action to identify and work around such cases, and as such the user should be able to change it easily in the default config file. The fix is to partially revert our delta that ignored a Debian patch: instead of ignoring the patch entirely, we modify it to only affect the default configuration file, and in a way that matches our patchset. Using this approach will allow us to pick up on Debian's changes more easily during subsequent merges. [Test Plan] To easily check that the setting is taken into account, one can use 'openssl ciphers -s' $ openssl ciphers -v -s | wc -l # Uses the default value 30 $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=2' | wc -l 30 $ openssl ciphers -v -s 'DEFAULT:@SECLEVEL=3' | wc -l 24 $ vim /etc/ssl/openssl.cf # edit the config file to bump the seclevel to 3 $ openssl ciphers -v -s | wc -l # Uses the new value from the config file 24 [Where problems could occur] The changes could break the overall configuration of OpenSSL! [Origin report] openssl.cnf as provided misses some directive, which make it a bit difficult to change security level, which since openssl 3 disables SHA1 signatures. See also this Debian bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1010360 and the committed fix: https://salsa.debian.org/debian/openssl/-/commit/b507914c40270e32cde6afcc8af93707c225e7f4 Can you please sync this change in Ubuntu openssl? This way one should just add a single directive to change the security level. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1972056/+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 1974037] Re: openssl: EVP_EC_gen() segfault without init
This bug was fixed in the package openssl - 3.0.3-5ubuntu2
---
openssl (3.0.3-5ubuntu2) kinetic; urgency=medium
* d/p/Set-systemwide-default-settings-for-libssl-users: don't comment out
the CipherString string to avoid an empty section.
-- Simon Chopin Tue, 31 May 2022 13:02:15 +0200
** Changed in: openssl (Ubuntu Kinetic)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1974037
Title:
openssl: EVP_EC_gen() segfault without init
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Jammy:
Confirmed
Status in openssl source package in Kinetic:
Fix Released
Status in openssl package in Debian:
Fix Released
Bug description:
[Impact]
The fix for
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1968997 has
broken some code paths as the new string comparison functions now need
initialization, triggering segafults.
The provided debdiff fixes the immediate issue and also settles on a
new implementation not requiring the initialization in the first
place.
[Test Plan]
Since this is a regression fix, we first need to check that the
original bug hasn't cropped up again:
sudo locale-gen tr_TR.UTF-8
LANG=C curl https://ubuntu.com/ > /dev/null # This work
LANG=tr_TF.UTF-8 curl https://ubuntu.com/ > /dev/null # This should work as
well
For the regression itself:
sudo apt install libssl-dev
cat < openssl_test.c
#include
int main()
{
EVP_PKEY_Q_keygen(NULL, NULL, "EC", "P-256");
}
EOF
gcc openssl_test.c -lcrypto -lssl -o openssl_test
./openssl_test
[Where problems could occur]
This new patch set is relatively massive, on top of another massive one.
Some new regressions could crop up of a similar kind. Furthermore, the
homegrown string comparison function could be buggy, leading to algorithm
name mismatches.
[Other info]
The patches all come from upstream and have been merged on their 3.0
maintenance branch.
[Original report]
Source: sscg
Version: 3.0.2-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/logs.php?pkg=sscg=3.0.2-1%2Bb1
...
1/10 generate_rsa_key_test FAIL 0.01s killed by signal 11
SIGSEGV
04:32:21 MALLOC_PERTURB_=87
/<>/obj-x86_64-linux-gnu/generate_rsa_key_test
...
Summary of Failures:
1/10 generate_rsa_key_test FAIL 0.01s killed by signal
11 SIGSEGV
Ok: 9
Expected Fail: 0
Fail: 1
Unexpected Pass:0
Skipped:0
Timeout:0
dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8
MESON_TESTTHREADS=4 ninja test returned exit code 1
make: *** [debian/rules:6: binary-arch] Error 25
This has also been reported on the openssl-users mailing list:
https://www.mail-archive.com/openssl-users@openssl.org/msg90830.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1974037/+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 1977564] Re: wireplumber conflicts with pipewire-media-session & needs fixing
The pipewire-media-session postrm is:
#!/bin/sh
set -e
# Automatically added by dh_installsystemduser/13.7.1ubuntu1
if [ "$1" = "remove" ]; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/usr/bin/deb-systemd-helper" ] ;
then
deb-systemd-helper --user mask 'pipewire-media-session.service'
>/dev/null || true
fi
fi
if [ "$1" = "purge" ]; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/usr/bin/deb-systemd-helper" ] ;
then
deb-systemd-helper --user purge
'pipewire-media-session.service' >/dev/null || true
deb-systemd-helper --user unmask
'pipewire-media-session.service' >/dev/null || true
fi
fi
# End automatically added section
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1977564
Title:
wireplumber conflicts with pipewire-media-session & needs fixing
Status in pipewire-media-session package in Ubuntu:
Triaged
Status in ubuntu-meta package in Ubuntu:
Triaged
Status in wireplumber package in Ubuntu:
Triaged
Status in pipewire-media-session package in Debian:
Confirmed
Bug description:
This issue was reported on IRC and we should probably fix it before
installing wireplumber by default so I'm setting the block-proposed
tag.
https://i.imgur.com/L5VFZO8.png
wireplumber is apparently too forceful in how it enables PipeWire.
Both Arch Linux and Debian had to
https://archlinux.org/news/undone-replacement-of-pipewire-media-
session-with-wireplumber/
Is it necessary for wireplumber to conflict with pipewire-media-
session?
Should we add Replaces?
What files does pipewire-media-session need to clean up when it is
removed?
See https://salsa.debian.org/gnome-team/gnome-remote-
desktop/-/commit/52799cfd for an example of how files that aren't
technically conffiles can be removed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pipewire-media-session/+bug/1977564/+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. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. - So this update introduces a very breaking change to an LTS release, - while LTS releases should be stable. + So this update introduces a very breaking change in IPv6 source address + selection to an LTS release, while LTS releases should be stable. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of 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: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address
[Touch-packages] [Bug 1977630] Re: machinectl pull-tar/pull-raw Operation not permitted
To add to that, this is the error when trying to pull an image $ machinectl pull-tar --verify=no https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz test ... Got 98% of https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz. 1s left at 3.6M/s. Got 99% of https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz. 200ms left at 3.6M/s. Download of https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz complete. Failed to rename to final image name to /var/lib/machines/.tar-https:\x2f\x2fcloud-images\x2eubuntu\x2ecom\x2fjammy\x2fcurrent\x2fjammy-server-cloudimg-amd64-root\x2etar\x2exz.\x2216765cac-5e045b7e29b80\x22: Operation not permitted Exiting. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1977630 Title: machinectl pull-tar/pull-raw Operation not permitted Status in systemd package in Ubuntu: New Bug description: There is a bug in systemd 249, where one can't pull any images. This was fixed in version 250, and never got backported. (FIX: https://github.com/systemd/systemd/commit/c40d82abf7b23803aa7394a7a7e24c40c32af851) Hopefully this can be addressed. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.1 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 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jun 4 04:51:42 2022 InstallationDate: Installed on 2022-06-01 (2 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1977630/+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. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. + So this update introduces a very breaking change to an LTS release, + while LTS releases should be stable. + I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of 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: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. So this update introduces a very breaking change to an LTS release, while LTS releases should be stable. I should note that the bug
[Touch-packages] [Bug 1958019]
(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: 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 1958019]
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), > -- 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 1977564] Re: wireplumber conflicts with pipewire-media-session & needs fixing
> Is it necessary for wireplumber to conflict with pipewire-media-session? > Should we add Replaces? wireplumber already conflicts/replaces pipewire-media-session It was not shown in the image I posted on IRC, but pipewire-media- session was 'removed' at the start of the apt full-upgrade Sadly it was removed and NOT purged Currently in Kubuntu Kinetic it is required to 'apt purge pipewire- media-session' to get things working if you also remove pulseaudio to complete the pipewire switch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1977564 Title: wireplumber conflicts with pipewire-media-session & needs fixing Status in pipewire-media-session package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: Triaged Status in wireplumber package in Ubuntu: Triaged Status in pipewire-media-session package in Debian: Confirmed Bug description: This issue was reported on IRC and we should probably fix it before installing wireplumber by default so I'm setting the block-proposed tag. https://i.imgur.com/L5VFZO8.png wireplumber is apparently too forceful in how it enables PipeWire. Both Arch Linux and Debian had to https://archlinux.org/news/undone-replacement-of-pipewire-media- session-with-wireplumber/ Is it necessary for wireplumber to conflict with pipewire-media- session? Should we add Replaces? What files does pipewire-media-session need to clean up when it is removed? See https://salsa.debian.org/gnome-team/gnome-remote- desktop/-/commit/52799cfd for an example of how files that aren't technically conffiles can be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire-media-session/+bug/1977564/+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. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting - net.ipv6.conf.all.use_tempaddr = 0 and - net.ipv6.conf..use_tempaddr = 0 with sysctl also no longer - has any effect. + net.ipv6.conf.all.use_tempaddr=0 and + net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has + any effect. - Removing the SLAAC addresses with `ip addr del` or disabling RA's + Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManager 1.38.0 on Debian sid. That just prefers DHCPv6 addresses when available, like it should. /etc/os-release: PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; UBUNTU_CODENAME=jammy nmcli -v: nmcli tool, version 1.36.6 -- You received this bug notification because you are a member of 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: New Bug description: My network has both DHCPv6 and SLAAC for IPv6. From both a privacy perspective and readability reasons, DHCPv6 should *always* be preferred over SLAAC addresses when available. NetworkManager has always been able to adhere to that by simply setting ip6.privacy=0 for the connection. So if you would - for instance - run `curl ifconfig.co`, the DHCPv6 address would be used to connect to the outside world. Since the update to 1.36.6, this is no longer the case. NetworkManager now routes outgoing traffic through the SLAAC address, even if ip6.privacy=0 is set for the connection. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf..use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's altogether is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. Looking at the changelog of NetworkManager 1.36.6, things regarding IP address order and temporary addresses have been changed in that release: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 addresses. With NetworkManager 1.36.4 this was not the case. (The Linux kernel uses the address highest in the list as preferred.) This can break many real-life use cases. For instance, my router gives out static leases to my machines. Those addresses are whitelisted in all kinds of firewalls to allow me to access servers for my work. Now that the "wrong" address is being preferred for outgoing traffic (a SLAAC address that I have no influence on), I am being locked out of the servers in question unless I forcefully remove the addresses or disable SLAAC on my router, so my outgoing traffic is being routed through the DHCPv6 address again. I should note that the bug is not present in NetworkManager
