[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall
** Changed in: libseccomp (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1944436 Title: Please backport support for "close_range" syscall Status in libseccomp package in Ubuntu: New Bug description: Please backport support for the "close_range" syscall .. may be as simple as cherrypicking https://github.com/seccomp/libseccomp/commit/01e5750e7c84bb14e5a5410c924bed519209db06 from upstream. I've hit problems running buildah in a systemd-nspawn container, but this will probably affect people trying to run modern code in other container systems as well, e.g. docker. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libseccomp2 2.5.1-1ubuntu1~20.04.1 ProcVersionSignature: Ubuntu 5.4.0-84.94-generic 5.4.133 Uname: Linux 5.4.0-84-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.20 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: Xpra Date: Tue Sep 21 15:10:54 2021 InstallationDate: Installed on 2017-01-08 (1717 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: libseccomp UpgradeStatus: Upgraded to focal on 2021-09-02 (19 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1944436/+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 1949030] [NEW] pip in venv does not see that python3-opencv is already installed
Public bug reported: I have the python3-opencv packaged installed. Still if I create a venv with system site packages and try to install opencv: python3 -m venv --system-site-packages tmp ./tmp/bin/pip install opencv-python It will install opencv from pypi instead of ignoring it as it does for numpy for example: ./tmp/bin/pip install numpy Requirement already satisfied: numpy in /usr/lib/python3/dist-packages (1.19.5) The problem seems to be that numpy installs the folder: /usr/lib/python3/dist-packages/numpy-1.19.5.egg-info/ While opencv does not create any such egg-info folder. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: python3-opencv 4.5.3+dfsg-1ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 22:28:12 2021 InstallationDate: Installed on 2020-01-07 (659 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: opencv UpgradeStatus: Upgraded to impish on 2021-10-27 (0 days ago) ** Affects: opencv (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to opencv in Ubuntu. https://bugs.launchpad.net/bugs/1949030 Title: pip in venv does not see that python3-opencv is already installed Status in opencv package in Ubuntu: New Bug description: I have the python3-opencv packaged installed. Still if I create a venv with system site packages and try to install opencv: python3 -m venv --system-site-packages tmp ./tmp/bin/pip install opencv-python It will install opencv from pypi instead of ignoring it as it does for numpy for example: ./tmp/bin/pip install numpy Requirement already satisfied: numpy in /usr/lib/python3/dist-packages (1.19.5) The problem seems to be that numpy installs the folder: /usr/lib/python3/dist-packages/numpy-1.19.5.egg-info/ While opencv does not create any such egg-info folder. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: python3-opencv 4.5.3+dfsg-1ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 22:28:12 2021 InstallationDate: Installed on 2020-01-07 (659 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: opencv UpgradeStatus: Upgraded to impish on 2021-10-27 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/1949030/+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 1920836] Re: Show Extended Security Maintenence status
@chad.smith - agreed, these changes as currently proposed will need to be updated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1920836 Title: Show Extended Security Maintenence status Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: New Status in software-properties source package in Bionic: Fix Committed Status in software-properties source package in Focal: Fix Committed Status in software-properties source package in Hirsute: Fix Committed Bug description: [Impact] There is not currently a graphical method of determining if a system is subscribed to [Extended Security Maintenance](https://ubuntu.com/security/esm) updates. This is resolved by adding some [new UI](https://wiki.ubuntu.com/SoftwareUpdates#Extended_Security_Maintenance) to the software properties application. [Test Case] 1. Install latest version of Ubuntu advantage: $ sudo add-apt-repository ppa:ua-client/stable $ sudo apt update $ sudo apt upgrade 2. Open Software Properties 3. Go to Updates tab. Expected result: Information is shown that indicates if this system is using Extended Security Maintenance updates, when updates will supported until, and a link to upgrade to ESM. Observed result: No ESM information currently shown. [Where problems could occur] - Software properties could hit a bug getting a response from the ua app. The current code carefully checks if and what is returned, falling back to a safe default behavior. - Launching software properties could trigger a bug in the ua app. - Software properties could show incorrect information, causing confusion for the user. The solution uses information from distro-info and the ua app which means software-properties contains no data about ESM, and instead relies on these apps that can be updated if things change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836/+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 1948990] Re: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash
You can also apply the fix manually be editing /lib/systemd/system/bluetooth.service and changing: #Restart=on-failure to Restart=on-failure -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1948990 Title: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash Status in bluez package in Ubuntu: Fix Released Bug description: I had bluetooth crash (see logs below). After the crash, I attempted to restart bluetooth by pressing the On/Off switch in the top-right of the Bluetooth tab of gnome-control-center (it was set to off). After pressing the switch, the switch read "On", but the display of Bluetooth devices still appeared as it does when Bluetooth is off (it read "Bluetooth Turned Off\nTurn on to connect devices and receive file transfers."). I was able to remedy the situation by manually executing `sudo bluetoothd`. I did this while the above On/Off switch was "Off" and the Bluetooth device list said Bluetooth was off. After executing, the Bluetooth device list listed all my Bluetooth devices as expected. This is with bluetoothd 5.48. Bluetooth crash logs ``` 12:22:15 pulseaudio: (6856.168| 0.576) [pulseaudio] bluez5-util.c: Bluetooth daemon disappeared 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Main process exited, code=dumped, status=11/SEGV 12:22:15 kernel: bluetoothd[816]: segfault at 31 ip 562f7fa9bea2 sp 7ffd0d54b720 error 4 in bluetoothd[562f7fa0+f3000] 10:28:31 kernel: hid-generic 0005:046D:B019.0007: input,hidraw6: BLUETOOTH HID v0.06 Keyboard [MX Master 2S] on F4:D1:08:9E:7B:85 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) ``` ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.6 Uname: Linux 5.10.0-051000-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.26 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 13:00:09 2021 InstallationDate: Installed on 2021-01-04 (295 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1948990/+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 1948990] Re: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash
I don't think the GUI is meant to start bluetoothd at all. It only toggles the power state of the Bluetooth hardware. It assumes bluetoothd is always running. So failure to restart after a crash is a problem with bluez's systemd scripting. ** Package changed: gnome-control-center (Ubuntu) => bluez (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1948990 Title: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash Status in bluez package in Ubuntu: Fix Released Bug description: I had bluetooth crash (see logs below). After the crash, I attempted to restart bluetooth by pressing the On/Off switch in the top-right of the Bluetooth tab of gnome-control-center (it was set to off). After pressing the switch, the switch read "On", but the display of Bluetooth devices still appeared as it does when Bluetooth is off (it read "Bluetooth Turned Off\nTurn on to connect devices and receive file transfers."). I was able to remedy the situation by manually executing `sudo bluetoothd`. I did this while the above On/Off switch was "Off" and the Bluetooth device list said Bluetooth was off. After executing, the Bluetooth device list listed all my Bluetooth devices as expected. This is with bluetoothd 5.48. Bluetooth crash logs ``` 12:22:15 pulseaudio: (6856.168| 0.576) [pulseaudio] bluez5-util.c: Bluetooth daemon disappeared 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Main process exited, code=dumped, status=11/SEGV 12:22:15 kernel: bluetoothd[816]: segfault at 31 ip 562f7fa9bea2 sp 7ffd0d54b720 error 4 in bluetoothd[562f7fa0+f3000] 10:28:31 kernel: hid-generic 0005:046D:B019.0007: input,hidraw6: BLUETOOTH HID v0.06 Keyboard [MX Master 2S] on F4:D1:08:9E:7B:85 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) ``` ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.6 Uname: Linux 5.10.0-051000-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.26 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 13:00:09 2021 InstallationDate: Installed on 2021-01-04 (295 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1948990/+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 1948990] Re: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash
It appears BlueZ upstream does not restart on failure, but in Ubuntu we turned on restart-on-failure in version 5.53-0ubuntu3. I suggest the best way to get that fix right now is to upgrade to Ubuntu 20.04. ** Changed in: bluez (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1948990 Title: Bluetooth does not turn on via gnome-control-center after bluetooth.service crash Status in bluez package in Ubuntu: Fix Released Bug description: I had bluetooth crash (see logs below). After the crash, I attempted to restart bluetooth by pressing the On/Off switch in the top-right of the Bluetooth tab of gnome-control-center (it was set to off). After pressing the switch, the switch read "On", but the display of Bluetooth devices still appeared as it does when Bluetooth is off (it read "Bluetooth Turned Off\nTurn on to connect devices and receive file transfers."). I was able to remedy the situation by manually executing `sudo bluetoothd`. I did this while the above On/Off switch was "Off" and the Bluetooth device list said Bluetooth was off. After executing, the Bluetooth device list listed all my Bluetooth devices as expected. This is with bluetoothd 5.48. Bluetooth crash logs ``` 12:22:15 pulseaudio: (6856.168| 0.576) [pulseaudio] bluez5-util.c: Bluetooth daemon disappeared 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Main process exited, code=dumped, status=11/SEGV 12:22:15 kernel: bluetoothd[816]: segfault at 31 ip 562f7fa9bea2 sp 7ffd0d54b720 error 4 in bluetoothd[562f7fa0+f3000] 10:28:31 kernel: hid-generic 0005:046D:B019.0007: input,hidraw6: BLUETOOTH HID v0.06 Keyboard [MX Master 2S] on F4:D1:08:9E:7B:85 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) ``` ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.6 Uname: Linux 5.10.0-051000-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.26 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 13:00:09 2021 InstallationDate: Installed on 2021-01-04 (295 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1948990/+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 1948978] Re: Thunderbird write e-mail window never released in wayland
*** This bug is a duplicate of bug 1932328 *** https://bugs.launchpad.net/bugs/1932328 Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1932328, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find. ** This bug has been marked a duplicate of bug 1932328 Thunderbird under Wayland does not correctly close (or manage) windows -- 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/1948978 Title: Thunderbird write e-mail window never released in wayland Status in xorg package in Ubuntu: New Bug description: If I run Thunderbird (latest version), when I write an e-mail or reply to an e-mail, a new window opens. When I send the e-mail, it works correctly and the e-mail is sent, but the red dot on the Thunderbird icon on the task bar never goes out. If I close or pkill Thunderbird, only the main Thunderbird window is released by the display manager and it is not possible to open Thunderbird again without logging out or restarting gdm3. This is with Wayland. There is no Thunderbird process left to kill. Everything works fine with Xorg, so on this computer running 21.10, I will be using Xorg instead of Wayland for now. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 14:53:29 2021 DistUpgraded: Fresh install DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Toshiba Corporation Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] Subsystem: Toshiba Corporation Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] InstallationDate: Installed on 2020-03-06 (600 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: TOSHIBA Satellite L305 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-20-generic root=UUID=baeb07e4-08ee-4d13-be78-7571c5723e1d ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/09/2009 dmi.bios.vendor: INSYDE dmi.bios.version: 2.20 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: Portable PC dmi.board.vendor: TOSHIBA dmi.board.version: Base Board Version dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Chassis Manufacturer dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnINSYDE:bvr2.20:bd12/09/2009:svnTOSHIBA:pnSatelliteL305:pvrPSLB8U-04X02F:skuMontevina_Fab:rvnTOSHIBA:rnPortablePC:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: dmi.product.family: Intel_Mobile dmi.product.name: Satellite L305 dmi.product.sku: Montevina_Fab dmi.product.version: PSLB8U-04X02F dmi.sys.vendor: TOSHIBA version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1948978/+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 1948990] [NEW] Bluetooth does not turn on via gnome-control-center after bluetooth.service crash
You have been subscribed to a public bug: I had bluetooth crash (see logs below). After the crash, I attempted to restart bluetooth by pressing the On/Off switch in the top-right of the Bluetooth tab of gnome-control-center (it was set to off). After pressing the switch, the switch read "On", but the display of Bluetooth devices still appeared as it does when Bluetooth is off (it read "Bluetooth Turned Off\nTurn on to connect devices and receive file transfers."). I was able to remedy the situation by manually executing `sudo bluetoothd`. I did this while the above On/Off switch was "Off" and the Bluetooth device list said Bluetooth was off. After executing, the Bluetooth device list listed all my Bluetooth devices as expected. This is with bluetoothd 5.48. Bluetooth crash logs ``` 12:22:15 pulseaudio: (6856.168| 0.576) [pulseaudio] bluez5-util.c: Bluetooth daemon disappeared 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Failed with result 'core-dump'. 12:22:15 systemd: bluetooth.service: Main process exited, code=dumped, status=11/SEGV 12:22:15 kernel: bluetoothd[816]: segfault at 31 ip 562f7fa9bea2 sp 7ffd0d54b720 error 4 in bluetoothd[562f7fa0+f3000] 10:28:31 kernel: hid-generic 0005:046D:B019.0007: input,hidraw6: BLUETOOTH HID v0.06 Keyboard [MX Master 2S] on F4:D1:08:9E:7B:85 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) 10:28:31 bluetoothd: bt_uhid_send: Invalid argument (22) ``` ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.6 Uname: Linux 5.10.0-051000-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.26 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 13:00:09 2021 InstallationDate: Installed on 2021-01-04 (295 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic third-party-packages -- Bluetooth does not turn on via gnome-control-center after bluetooth.service crash https://bugs.launchpad.net/bugs/1948990 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez 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 1948877] Re: Bluetooth headphones media buttons no longer work
** Tags added: impish ** Description changed: In KUbuntu 21.10, most media buttons in my bluetooth headphones stopped working. This includes the "play/pause" button, "play next" (calls after long press of volume increase), and "play previous" (long press of volume decrease). The volume +/- buttons themselves are working, but this seemingly is implemented entirely in the headphones and does not require any communication over bluetooth. - In previous ubuntu (20.04) these buttons worked, and I expect them + In previous ubuntu (21.04) these buttons worked, and I expect them working. My headset is Qumo Accord 3. Here is output of "inxi -Eaz" in terminal: - Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8 bus-ID: 1-7:3 chip-ID: 0bda:b008 class-ID: e001 -serial: -Report: hciconfig ID: hci0 rfk-id: 1 state: up address: bt-v: 2.1 lmp-v: 4.0 sub-v: 9f73 hci-v: 4.0 -rev: e2f -Info: acl-mtu: 820:8 sco-mtu: 255:16 link-policy: rswitch hold sniff park link-mode: slave accept -service-classes: rendering, capturing, object transfer, audio, telephony + Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8 bus-ID: 1-7:3 chip-ID: 0bda:b008 class-ID: e001 + serial: + Report: hciconfig ID: hci0 rfk-id: 1 state: up address: bt-v: 2.1 lmp-v: 4.0 sub-v: 9f73 hci-v: 4.0 + rev: e2f + Info: acl-mtu: 820:8 sco-mtu: 255:16 link-policy: rswitch hold sniff park link-mode: slave accept + service-classes: rendering, capturing, object transfer, audio, telephony Some possible workarounds that I found suggest to "modprobe uinput", but the uinput module does not get loaded (lsmod does not list it even after modprobe'ing). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1948877 Title: Bluetooth headphones media buttons no longer work Status in bluez package in Ubuntu: New Bug description: In KUbuntu 21.10, most media buttons in my bluetooth headphones stopped working. This includes the "play/pause" button, "play next" (calls after long press of volume increase), and "play previous" (long press of volume decrease). The volume +/- buttons themselves are working, but this seemingly is implemented entirely in the headphones and does not require any communication over bluetooth. In previous ubuntu (21.04) these buttons worked, and I expect them working. My headset is Qumo Accord 3. Here is output of "inxi -Eaz" in terminal: Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8 bus-ID: 1-7:3 chip-ID: 0bda:b008 class-ID: e001 serial: Report: hciconfig ID: hci0 rfk-id: 1 state: up address: bt-v: 2.1 lmp-v: 4.0 sub-v: 9f73 hci-v: 4.0 rev: e2f Info: acl-mtu: 820:8 sco-mtu: 255:16 link-policy: rswitch hold sniff park link-mode: slave accept service-classes: rendering, capturing, object transfer, audio, telephony Some possible workarounds that I found suggest to "modprobe uinput", but the uinput module does not get loaded (lsmod does not list it even after modprobe'ing). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1948877/+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 1812095] Re: console login loop after entering username followed by RETURN
*** This bug is a duplicate of bug 1813873 *** https://bugs.launchpad.net/bugs/1813873 daniel-sokolov, this bug was fixed in Ubuntu kernels two and a half years ago. Do you really have such an old kernel? I suggest asking for help in Mint support channels -- hopefully someone can walk you through installing a newer kernel through a rescue system. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1812095 Title: console login loop after entering username followed by RETURN Status in shadow package in Ubuntu: Confirmed Bug description: login: password: Just do nothing. About two seconds later ... login: password: login: password: login: password: After this being displayed three times: "Too many failure" or so and login is restarting. You cant login at all. Only solution: clear the password for the account you want to login with. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: login 1:4.5-1ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-14.15-generic 4.18.20 Uname: Linux 4.18.0-14-generic x86_64 ApportVersion: 2.20.10-0ubuntu13.1 Architecture: amd64 CurrentDesktop: XFCE Date: Wed Jan 16 19:34:30 2019 InstallationDate: Installed on 2011-10-19 (2645 days ago) InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012) SourcePackage: shadow UpgradeStatus: Upgraded to cosmic on 2018-11-03 (74 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1812095/+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 1869267] Re: /etc/login.defs contains a non-ASCII character
This is in the debian/login.defs file, and was replaced at least before bionic with a proper ascii ', so I'm targeting this to xenial. ** Changed in: shadow (Ubuntu) Status: New => Fix Released ** Also affects: shadow (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: shadow (Ubuntu Xenial) Status: New => Confirmed ** Changed in: shadow (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1869267 Title: /etc/login.defs contains a non-ASCII character Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Confirmed Bug description: 1) OS: Ubuntu 16.04.6 LTS 2) Package: login 1:4.2-3.1ubuntu5.4 amd64 from xenial-updates/main 3) After installing this package, I expect /etc/login.defs to contain only ASCII characters. 4) Instead, /etc/login.defs contains an Acute Accent (Unicode U+00B4) on line 221 in a comment: === Quote From File === # If set to yes, userdel will remove the user´s group if it contains no === End Quote === This causes a problem in SaltStack: https://github.com/saltstack/salt/issues/55695 SaltStack does recognize that they should do a better job at loading this file and is planning on fixing its problem. But I still question this: Should we expect /etc/login.defs to contain ASCII characters only? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: login 1:4.2-3.1ubuntu5.4 ProcVersionSignature: Ubuntu 4.4.0-1101.112-aws 4.4.208 Uname: Linux 4.4.0-1101-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.21 Architecture: amd64 Date: Thu Mar 26 17:46:26 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1869267/+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 1923262] Re: backup /etc/passwd- file should be mode 0600
I appreciate you bringing this to our attention, but (as shadow upstream maintainer) I'm going to join John in saying this should be wontfix. Now if you want to change the subject to also making /etc/passwd 600, then as Alexander points out that may be doable and have merit. But just hiding the backup file doesn't make sense, and as it would require extra code in the already fiddly backup code in shadow, there is regression concern. ** Changed in: shadow (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1923262 Title: backup /etc/passwd- file should be mode 0600 Status in shadow package in Ubuntu: Won't Fix Bug description: CIS hardening benchmarks (6.1.6) suggest that the /etc/passwd- file should be mode 0600 (or more restrictive). However, this file is 0644 after it is created when the /etc/passwd file is modified. (Ie, a hardening script that creates a hardened system for initial use could change this mode, but it will go out of compliance the next time a backup file is made.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1923262/+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 1928309] Re: usermod change home directory no tilde
Well that's just fascinating! :) This would be best reported at https://github.com/shadow- maint/shadow/issues. Would you mind opening an issue there? ** Changed in: shadow (Ubuntu) Status: New => Confirmed ** Changed in: shadow (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1928309 Title: usermod change home directory no tilde Status in shadow package in Ubuntu: Confirmed Bug description: I believe usermod is in the passwd package. Running `sudo usermod -d /home/username username` will result in correct terminal output as `username@hostname:~$` But running `sudo usermod -d /home/username/ username` will output `username@/home/username:~$`, since usermod does not drop the trailing forward slash and the string "/home/username/" does not match with "/home/username". This is a result of tab completion causing the extra forward slash. This bug is purely cosmetic. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: passwd 1:4.8.1-1ubuntu5.20.04 ProcVersionSignature: User Name 5.4.0-1048.50-aws 5.4.106 Uname: Linux 5.4.0-1048-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.17 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu May 13 08:08:56 2021 Ec2AMI: ami-0d382e80be7ffdae5 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-west-1b Ec2InstanceType: c5n.4xlarge Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1928309/+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 1920836] Re: Show Extended Security Maintenence status
@robert, looks like we should reject this queued upload and put up a separate set of uploads. Recommending reject here and we can work this & next week to get you MRs to support current best-practices for interacting with ua status.json. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1920836 Title: Show Extended Security Maintenence status Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: New Status in software-properties source package in Bionic: Fix Committed Status in software-properties source package in Focal: Fix Committed Status in software-properties source package in Hirsute: Fix Committed Bug description: [Impact] There is not currently a graphical method of determining if a system is subscribed to [Extended Security Maintenance](https://ubuntu.com/security/esm) updates. This is resolved by adding some [new UI](https://wiki.ubuntu.com/SoftwareUpdates#Extended_Security_Maintenance) to the software properties application. [Test Case] 1. Install latest version of Ubuntu advantage: $ sudo add-apt-repository ppa:ua-client/stable $ sudo apt update $ sudo apt upgrade 2. Open Software Properties 3. Go to Updates tab. Expected result: Information is shown that indicates if this system is using Extended Security Maintenance updates, when updates will supported until, and a link to upgrade to ESM. Observed result: No ESM information currently shown. [Where problems could occur] - Software properties could hit a bug getting a response from the ua app. The current code carefully checks if and what is returned, falling back to a safe default behavior. - Launching software properties could trigger a bug in the ua app. - Software properties could show incorrect information, causing confusion for the user. The solution uses information from distro-info and the ua app which means software-properties contains no data about ESM, and instead relies on these apps that can be updated if things change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836/+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 1948877] Re: Bluetooth headphones media buttons no longer work
Exact package causing the issue is not obvious, but I add bluez. ** Package changed: ubuntu => bluez (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1948877 Title: Bluetooth headphones media buttons no longer work Status in bluez package in Ubuntu: New Bug description: In KUbuntu 21.10, most media buttons in my bluetooth headphones stopped working. This includes the "play/pause" button, "play next" (calls after long press of volume increase), and "play previous" (long press of volume decrease). The volume +/- buttons themselves are working, but this seemingly is implemented entirely in the headphones and does not require any communication over bluetooth. In previous ubuntu (20.04) these buttons worked, and I expect them working. My headset is Qumo Accord 3. Here is output of "inxi -Eaz" in terminal: Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8 bus-ID: 1-7:3 chip-ID: 0bda:b008 class-ID: e001 serial: Report: hciconfig ID: hci0 rfk-id: 1 state: up address: bt-v: 2.1 lmp-v: 4.0 sub-v: 9f73 hci-v: 4.0 rev: e2f Info: acl-mtu: 820:8 sco-mtu: 255:16 link-policy: rswitch hold sniff park link-mode: slave accept service-classes: rendering, capturing, object transfer, audio, telephony Some possible workarounds that I found suggest to "modprobe uinput", but the uinput module does not get loaded (lsmod does not list it even after modprobe'ing). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1948877/+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 1948877] [NEW] Bluetooth headphones media buttons no longer work
You have been subscribed to a public bug: In KUbuntu 21.10, most media buttons in my bluetooth headphones stopped working. This includes the "play/pause" button, "play next" (calls after long press of volume increase), and "play previous" (long press of volume decrease). The volume +/- buttons themselves are working, but this seemingly is implemented entirely in the headphones and does not require any communication over bluetooth. In previous ubuntu (20.04) these buttons worked, and I expect them working. My headset is Qumo Accord 3. Here is output of "inxi -Eaz" in terminal: Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8 bus-ID: 1-7:3 chip-ID: 0bda:b008 class-ID: e001 serial: Report: hciconfig ID: hci0 rfk-id: 1 state: up address: bt-v: 2.1 lmp-v: 4.0 sub-v: 9f73 hci-v: 4.0 rev: e2f Info: acl-mtu: 820:8 sco-mtu: 255:16 link-policy: rswitch hold sniff park link-mode: slave accept service-classes: rendering, capturing, object transfer, audio, telephony Some possible workarounds that I found suggest to "modprobe uinput", but the uinput module does not get loaded (lsmod does not list it even after modprobe'ing). ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: bot-comment -- Bluetooth headphones media buttons no longer work https://bugs.launchpad.net/bugs/1948877 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez 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 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Uploaded to H/F/B. (debdiffs in bug 1946804) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw insert 1 reject from 1.0.0.0/8 to any port 22 ufw insert 2 allow from any to any port 22 ...which was later updated to be... ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp ufw insert 2 allow from any to any port 22 proto
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Uploaded to I/H/F/B. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Patch added: "ufw-impish.debdiff" https://bugs.launchpad.net/ufw/+bug/1946804/+attachment/5536527/+files/ufw-impish.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Patch added: "ufw-bionic.debdiff" https://bugs.launchpad.net/ufw/+bug/1946804/+attachment/5536530/+files/ufw-bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Patch added: "ufw-focal.debdiff" https://bugs.launchpad.net/ufw/+bug/1946804/+attachment/5536529/+files/ufw-focal.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Verified test packages (ppa:mfo/lp1946804) for the Hirsute, Focal, and Bionic releases. ... Without the patch: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/00.0.0.0/0tcp dpt:22 ACCEPT tcp -- 2.2.2.2 0.0.0.0/0tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0tcp spt: With the patch: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/00.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.1 0.0.0.0/0tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0tcp spt: ... Versions tested (original/without patch) I: Version: 0.36.1-1 H: Version: 0.36-7.1 F: Version: 0.36-6 B: Version: 0.36-0ubuntu0.18.04.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Patch added: "ufw-hirsute.debdiff" https://bugs.launchpad.net/ufw/+bug/1946804/+attachment/5536528/+files/ufw-hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Verified test packages (ppa:mfo/lp1946804) for the Impish, Hirsute, Focal, and Bionic releases on Oracle Cloud's 'BM.Standard1.36' systems. (Impish/Hirsute: Focal and do-release-upgrade.) ... Without the patch, the system boot stalls. With the patch, the system boot continues. (Note: netfilter-persistent.service needed to be disabled, otherwise it flushes ufw's rules.) ... The output of `iptables -L -n` was the same with/without the patch. # diff iptables.before iptables.after; echo $? 0 # wc -l iptables.before iptables.after 170 iptables.before 170 iptables.after 340 total ... Versions tested (original/without patch) I: Version: 0.36.1-1 H: Version: 0.36-7.1 F: Version: 0.36-6 B: Version: 0.36-0ubuntu0.18.04.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: In Progress Status in ufw source package in Focal: In Progress Status in ufw source package in Hirsute: In Progress Status in ufw source package in Impish: In Progress Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554]
[Touch-packages] [Bug 1948978] [NEW] Thunderbird write e-mail window never released in wayland
Public bug reported: If I run Thunderbird (latest version), when I write an e-mail or reply to an e-mail, a new window opens. When I send the e-mail, it works correctly and the e-mail is sent, but the red dot on the Thunderbird icon on the task bar never goes out. If I close or pkill Thunderbird, only the main Thunderbird window is released by the display manager and it is not possible to open Thunderbird again without logging out or restarting gdm3. This is with Wayland. There is no Thunderbird process left to kill. Everything works fine with Xorg, so on this computer running 21.10, I will be using Xorg instead of Wayland for now. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 14:53:29 2021 DistUpgraded: Fresh install DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Toshiba Corporation Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] Subsystem: Toshiba Corporation Mobile 4 Series Chipset Integrated Graphics Controller [1179:ff67] InstallationDate: Installed on 2020-03-06 (600 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: TOSHIBA Satellite L305 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-20-generic root=UUID=baeb07e4-08ee-4d13-be78-7571c5723e1d ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/09/2009 dmi.bios.vendor: INSYDE dmi.bios.version: 2.20 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: Portable PC dmi.board.vendor: TOSHIBA dmi.board.version: Base Board Version dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Chassis Manufacturer dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnINSYDE:bvr2.20:bd12/09/2009:svnTOSHIBA:pnSatelliteL305:pvrPSLB8U-04X02F:skuMontevina_Fab:rvnTOSHIBA:rnPortablePC:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: dmi.product.family: Intel_Mobile dmi.product.name: Satellite L305 dmi.product.sku: Montevina_Fab dmi.product.version: PSLB8U-04X02F dmi.sys.vendor: TOSHIBA version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish ubuntu wayland-session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1948978 Title: Thunderbird write e-mail window never released in wayland Status in xorg package in Ubuntu: New Bug description: If I run Thunderbird (latest version), when I write an e-mail or reply to an e-mail, a new window opens. When I send the e-mail, it works correctly and the e-mail is sent, but the red dot on the Thunderbird icon on the task bar never goes out. If I close or pkill Thunderbird, only the main Thunderbird window is released by the display manager and it is not possible to open Thunderbird again without logging out or restarting gdm3. This is with Wayland. There is no Thunderbird process left to kill. Everything works fine with Xorg, so on this computer running 21.10, I will be using Xorg instead of Wayland for now. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 14:53:29 2021 DistUpgraded: Fresh install DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Toshiba Corporation Mobile 4 Series Chipset Integrated Graphics
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Description changed: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. -(e.g., Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) + (e.g., Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable + + * Observed: system may stall immediately if no prior iptables rules. + * Expected: system continues working. + + * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
** Description changed: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. + [Test Steps] - - Functional tests summary - - Attempted: 22 (3339 individual tests) - Skipped: 0 - Errors: 0 + * Install Ubuntu on an iSCSI (or other network-based) root filesystem. + + * sudo ufw enable + * sudo reboot + + * Observed: system boot stalls once ufw.service starts (see below.) + * Expected: system boot should move on. + + [Regression Potential] + + * Potential regressions would be observed on ufw start/reload, +when iptables rules are configured. + + * The resulting iptables configuration has been compared +before/after the change, with identical rules on both. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 8d d8 00 00 08 00 [ 436.198807]
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
** Description changed: + [Impact] + + * The deletion of a rule without the 'proto' field +that has a similar rule *with* the 'proto' field +might delete the wrong rule (the latter). + + * This might cause services to be inaccessible or +incorrectly allowed, depending on rule ordering +(read original description below for examples.) + + [Test Steps] + + * Add rules: +ufw allow from 1.1.1.1 port proto tcp +ufw allow from 2.2.2.2 port proto tcp +ufw allow from 1.1.1.1 port + + * Check iptables: +iptables -L ufw-user-input -n +... +ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: +ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: +ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: +ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: + + * Delete the third rule above +ufw status numbered +yes | ufw delete 3 + + * Check iptables again: +iptables -L ufw-user-input -n + +Observed: (deleted tcp line from first rule, and udp line from third rule) +... +ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: +ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: + +Expected: (deleted both tcp and udp lines from third rule) +... +ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: +ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: + + [Regression Potential] + + * Potential regressions would be observed when deleting rules. + + * This fix has been suggested for SRU by jdstrand [1], +and has already been available in 21.04 and the snap. + + [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 + + [Original Description] + UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw insert 1 reject from 1.0.0.0/8 to any port 22 ufw insert 2 allow from any to any port 22 ...which was later updated to be... ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp ufw insert 2 allow from any to any port 22 proto tcp yes | ufw delete 3 ...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible. A reboot is required to fix the issue, as it reloads the configuration to the expected order. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse
[Touch-packages] [Bug 1948698] Re: Update tzdata to version 2021e
verification of the tzdata update on bionic:
bdmurray@clean-bionic-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 21:59:59 2021 UT = Sat Oct 30 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 22:00:00 2021 UT = Sat Oct 30 00:00:00 2021 EET isdst=0
gmtoff=7200
bdmurray@clean-bionic-amd64:~$ sudo apt-get -qq install tzdata
Preconfiguring packages ...
(Reading database ... 205624 files and directories currently installed.)
Preparing to unpack .../tzdata_2021e-0ubuntu0.18.04_all.deb ...
Unpacking tzdata (2021e-0ubuntu0.18.04) over (2021a-2ubuntu0.18.04) ...
Setting up tzdata (2021e-0ubuntu0.18.04) ...
Current default time zone: 'America/Los_Angeles'
Local time is now: Wed Oct 27 10:21:39 PDT 2021.
Universal Time is now: Wed Oct 27 17:21:39 UTC 2021.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
bdmurray@clean-bionic-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 21:59:59 2021 UT = Fri Oct 29 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 22:00:00 2021 UT = Fri Oct 29 00:00:00 2021 EET isdst=0
gmtoff=7200
And confirmation that the SystemV time zones are still good to go:
bdmurray@clean-bionic-amd64:~$ diff <(zdump -v America/Phoenix | cut -d' '
-f2-) <(zdump -v SystemV/MST7 | cut -d' ' -f2-)
bdmurray@clean-bionic-amd64:~$
** Tags removed: verification-needed verification-needed-bionic
verification-needed-focal verification-needed-hirsute verification-needed-impish
** Tags added: verification-done verification-done-bionic
verification-done-focal verification-done-hirsute verification-done-impish
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Re: Update tzdata to version 2021e
verification of tzdata update on focal:
bdmurray@clean-focal-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 21:59:59 2021 UT = Sat Oct 30 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 22:00:00 2021 UT = Sat Oct 30 00:00:00 2021 EET isdst=0
gmtoff=7200
bdmurray@clean-focal-amd64:~$ sudo apt-get -qq install tzdata
Preconfiguring packages ...
(Reading database ... 267220 files and directories currently installed.)
Preparing to unpack .../tzdata_2021e-0ubuntu0.20.04_all.deb ...
Unpacking tzdata (2021e-0ubuntu0.20.04) over (2021a-2ubuntu0.20.04) ...
Setting up tzdata (2021e-0ubuntu0.20.04) ...
Current default time zone: 'America/Los_Angeles'
Local time is now: Wed Oct 27 10:08:30 PDT 2021.
Universal Time is now: Wed Oct 27 17:08:30 UTC 2021.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
bdmurray@clean-focal-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 21:59:59 2021 UT = Fri Oct 29 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 22:00:00 2021 UT = Fri Oct 29 00:00:00 2021 EET isdst=0
gmtoff=7200
And the icu data verification on focal:
bdmurray@clean-focal-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.creat
eTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 28'
3:00:00
bdmurray@clean-focal-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.creat
eTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 29'
2:00:00
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Re: Update tzdata to version 2021e
tzdata verification on hirsute:
bdmurray@clean-hirsute-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 21:59:59 2021 UT = Sat Oct 30 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 22:00:00 2021 UT = Sat Oct 30 00:00:00 2021 EET isdst=0
gmtoff=7200
bdmurray@clean-hirsute-amd64:~$ sudo apt-get -qq install tzdata
Preconfiguring packages ...
(Reading database ... 270990 files and directories currently installed.)
Preparing to unpack .../tzdata_2021e-0ubuntu0.21.04_all.deb ...
Unpacking tzdata (2021e-0ubuntu0.21.04) over (2021a-2ubuntu0.21.04) ...
Setting up tzdata (2021e-0ubuntu0.21.04) ...
Current default time zone: 'America/Los_Angeles'
Local time is now: Wed Oct 27 09:50:51 PDT 2021.
Universal Time is now: Wed Oct 27 16:50:51 UTC 2021.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
bdmurray@clean-hirsute-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 21:59:59 2021 UT = Fri Oct 29 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 22:00:00 2021 UT = Fri Oct 29 00:00:00 2021 EET isdst=0
gmtoff=7200
and icudata verification:
bdmurray@clean-hirsute-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.cre
ateTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 28'
3:00:00
bdmurray@clean-hirsute-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.cre
ateTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 29'
2:00:00
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Re: Update tzdata to version 2021e
tzdata verification on impish:
bdmurray@clean-impish-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 21:59:59 2021 UT = Sat Oct 30 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Fri Oct 29 22:00:00 2021 UT = Sat Oct 30 00:00:00 2021 EET isdst=0
gmtoff=7200
bdmurray@clean-impish-amd64:~$ apt-cache policy tzdata
tzdata:
Installed: 2021e-0ubuntu0.21.10
Candidate: 2021e-0ubuntu0.21.10
Version table:
*** 2021e-0ubuntu0.21.10 500
500 http://archive.ubuntu.com/ubuntu impish-proposed/main amd64 Packages
500 http://archive.ubuntu.com/ubuntu impish-proposed/main i386 Packages
100 /var/lib/dpkg/status
2021a-2ubuntu1 500
500 http://192.168.10.7/ubuntu impish/main amd64 Packages
500 http://192.168.10.7/ubuntu impish/main i386 Packages
bdmurray@clean-impish-amd64:~$ zdump -v Asia/Gaza | grep 2021
Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0
gmtoff=7200
Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 21:59:59 2021 UT = Fri Oct 29 00:59:59 2021 EEST isdst=1
gmtoff=10800
Asia/Gaza Thu Oct 28 22:00:00 2021 UT = Fri Oct 29 00:00:00 2021 EET isdst=0
gmtoff=7200
and the icudata verification:
bdmurray@clean-impish-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.crea
teTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 28'
3:00:00
bdmurray@clean-impish-amd64:~$ python3 -c 'from datetime import datetime; from
icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.crea
teTimeZone("Asia/Gaza")); print(str(tz.utcoffset(datetime(2021, 10, 29'
2:00:00
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1916250] Please test proposed package
Hello Rolf, or anyone else affected, Accepted libsignon-glib into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libsignon- glib/2.1-3ubuntu0.21.04 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: Fix Committed Status in libsignon-glib source package in Impish: Fix Committed Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1916250] Please test proposed package
Hello Rolf, or anyone else affected, Accepted libsignon-glib into impish-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libsignon- glib/2.1-3ubuntu0.21.10 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- impish to verification-done-impish. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-impish. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: libsignon-glib (Ubuntu Hirsute) Status: In Progress => Fix Committed ** Tags added: verification-needed-hirsute -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: Fix Committed Status in libsignon-glib source package in Impish: Fix Committed Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy)
11:45 vorlon: could you take a look at bug 1916250 for me please? I'm not sure it's right, but nor am I sure it's wrong. 14:29 rbasak: gir1.2-signon-2.0 exists in hirsute and later; gir1.2-signon-1.0 exists in focal; we support upgrades from the LTS to either the next LTS, or to the next supported non-LTS release. So there are upgrade paths to hirsute now, and to impish once hirsute EOLs, so yes it's correct to SRU this fix 17:00 vorlon: I agree it needs SRUing. My question is if a sole unversioned Replaces is correct. 17:00 rbasak: ah, that should be fine ** Changed in: libsignon-glib (Ubuntu Impish) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: Fix Committed Status in libsignon-glib source package in Impish: Fix Committed Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy)
** Tags added: focal2jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: In Progress Status in libsignon-glib source package in Impish: In Progress Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1928393] Re: linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0] retry page fault"
The reverts are in the latest firmware tree: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amdgpu?id=d7b50e61669dc137924337d03d09b8986eb752a3 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amdgpu?id=d843e520a4b0d92b986645548d11ade3b9b239a4 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amdgpu?id=99d72504bff7ab40c261b8509c0b9d8abf98b296 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1928393 Title: linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0] retry page fault" Status in amd: New Status in linux-firmware package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Bug description: After upgrading linux-firmware from 1.190.5 to 1.197 (as part of the upgrade from Ubuntu 20.10 to 21.04), I started experiencing frequent and severe GPU instability. When this happens, I see this error in dmesg: [20061.061069] amdgpu :03:00.0: amdgpu: [gfxhub0] retry page fault (src_id:0 ring:0 vmid:1 pasid:32769, for process Xorg pid 1141 thread Xorg:cs0 pid 1236) [20061.061103] amdgpu :03:00.0: amdgpu: in page starting at address 0x80401000 from client 27 [20061.061135] amdgpu :03:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [20061.061147] amdgpu :03:00.0: amdgpu: Faulty UTCL2 client ID: TCP (0x8) [20061.061157] amdgpu :03:00.0: amdgpu: MORE_FAULTS: 0x1 [20061.061167] amdgpu :03:00.0: amdgpu: WALKER_ERROR: 0x0 [20061.061174] amdgpu :03:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [20061.061183] amdgpu :03:00.0: amdgpu: MAPPING_ERROR: 0x0 [20061.061189] amdgpu :03:00.0: amdgpu: RW: 0x0 I'll attach a couple of full dmesgs that I collected. Many of the times when this happens, the screen and keyboard freeze irreversibly (I tried waiting for more than 30 minutes, but it doesn't help). I can still log in via ssh though. When there's no freeze, I can continue using the computer normally, but the laptop fans keep running are always running and the battery depletes fast. There's probably something on a permanent loop either in the kernel or in the GPU. This bug happens several times a day, rendering the machine so unstable as to be almost unusable. It is a severe regression and I'm aghast that it passed AMD's Quality Assurance. After downgrading back to linux-firmware 1.190.5, the machine is back to the previous, mostly-reliable state. Which is to say, this bug is gone, I'm just left with the other amdgpu suspend bug I've learned to live with since I bought this computer. Please revert the amdgpu firmware in this package as soon as possible. This is unbearable. Relevant information: Ubuntu version: 21.04 Linux kernel: 5.11.0-17-generic x86_64 CPU model: AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx GPU: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c1) Laptop model: Lenovo Ideapad S145 To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1928393/+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 1160316] Re: HTTP Error 502: Bad Gateway when reporting a bug with apport
** Package changed: ubuntu => apport (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1160316 Title: HTTP Error 502: Bad Gateway when reporting a bug with apport Status in Apport: New Status in apport package in Ubuntu: Confirmed Bug description: When trying to report a bug using Apport on Raring, I get a "HTTP Error 502: Bad Gateway" error even though I am properly connected to the internet at the time (browsing web pages and sending/receiving email). My connection to the Internet is via an ADSL router, IP address and gateway Steps to reproduce: 1. Open a terminal 2. Type ubuntu-bug apport 3. Apport starts and collects data Expected bahaviour: Apport opens a browser window as normal to enable the user to complete the bug report. Actual behaviour: Apport shows the error message in the attached screenshot. For information, here is the output I get regarding my network connection: $ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:24:d7:c7:b9:94 inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::224:d7ff:fec7:b994/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1071072 errors:0 dropped:0 overruns:0 frame:0 TX packets:360755 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:704047081 (704.0 MB) TX bytes:92144451 (92.1 MB) $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 192.168.0.1 0.0.0.0 UG0 00 wlan0 link-local * 255.255.0.0 U 1000 00 wlan0 192.168.0.0 * 255.255.255.0 U 9 00 wlan0 To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1160316/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy)
https://packages.ubuntu.com/search?keywords=gir1.2-signon -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: In Progress Status in libsignon-glib source package in Impish: In Progress Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy)
Oh, Robie, come on now. You already asked that question and an answer was given in #3 and #4. Too bad that was so long ago, but it's not my fault. "In this case, in essence the package name is already the versioning." and "IOW, gir1.2-signon-1.0 isn't going to see any further upstream work and Debian won't reintroduce it either. That line ends with Debian stable." You know guys, it's really frustrating to do all the work and then have to do it over and over again and again. Sometimes for years without getting an inch closer to getting a fix uploaded. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: In Progress Status in libsignon-glib source package in Impish: In Progress Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1160316] [NEW] HTTP Error 502: Bad Gateway when reporting a bug with apport
You have been subscribed to a public bug: When trying to report a bug using Apport on Raring, I get a "HTTP Error 502: Bad Gateway" error even though I am properly connected to the internet at the time (browsing web pages and sending/receiving email). My connection to the Internet is via an ADSL router, IP address and gateway Steps to reproduce: 1. Open a terminal 2. Type ubuntu-bug apport 3. Apport starts and collects data Expected bahaviour: Apport opens a browser window as normal to enable the user to complete the bug report. Actual behaviour: Apport shows the error message in the attached screenshot. For information, here is the output I get regarding my network connection: $ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:24:d7:c7:b9:94 inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::224:d7ff:fec7:b994/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1071072 errors:0 dropped:0 overruns:0 frame:0 TX packets:360755 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:704047081 (704.0 MB) TX bytes:92144451 (92.1 MB) $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 192.168.0.1 0.0.0.0 UG0 00 wlan0 link-local * 255.255.0.0 U 1000 00 wlan0 192.168.0.0 * 255.255.255.0 U 9 00 wlan0 ** Affects: apport Importance: Undecided Status: New ** Affects: apport (Ubuntu) Importance: Undecided Status: Confirmed -- HTTP Error 502: Bad Gateway when reporting a bug with apport https://bugs.launchpad.net/bugs/1160316 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport 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 1948698] Re: Update tzdata to version 2021e
Hello Brian, or anyone else affected,
Accepted tzdata into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2021e-0ubuntu0.18.04 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: tzdata (Ubuntu Bionic)
Status: In Progress => Fix Committed
** Tags added: verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Please test proposed package
Hello Brian, or anyone else affected,
Accepted tzdata into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2021e-0ubuntu0.20.04 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Re: Update tzdata to version 2021e
Hello Brian, or anyone else affected,
Accepted tzdata into hirsute-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2021e-0ubuntu0.21.04 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: tzdata (Ubuntu Hirsute)
Status: In Progress => Fix Committed
** Tags added: verification-needed-hirsute
** Changed in: tzdata (Ubuntu Focal)
Status: In Progress => Fix Committed
** Tags added: verification-needed-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
Fix Committed
Status in tzdata source package in Focal:
Fix Committed
Status in tzdata source package in Hirsute:
Fix Committed
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1948698] Re: Update tzdata to version 2021e
Hello Brian, or anyone else affected,
Accepted tzdata into impish-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/tzdata/2021e-0ubuntu0.21.10 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
impish to verification-done-impish. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-impish. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: tzdata (Ubuntu Impish)
Status: In Progress => Fix Committed
** Tags added: verification-needed verification-needed-impish
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1948698
Title:
Update tzdata to version 2021e
Status in tzdata package in Ubuntu:
In Progress
Status in tzdata source package in Bionic:
In Progress
Status in tzdata source package in Focal:
In Progress
Status in tzdata source package in Hirsute:
In Progress
Status in tzdata source package in Impish:
Fix Committed
Bug description:
New upstream version affecting the following timestamp:
$region/$timezone = Asia/Gaza
Verification is done with 'zdump'. The first timezone that gets
changed in the updated package is dumped with 'zdump -v
$region/$timezone_that_changed' (this needs to be greped for in
/usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
compared to the same output after the updated package got installed.
If those are different the verification is considered done.
[Test Case for all releases]
1) zdump -v Asia/Gaza 2021
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
[Test Case for releases >= 20.04 LTS]
1) sudo apt-get install python3-icu
2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo,
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia'));
print(str(tz.utcoffset(datetime(2021, 9, 26'
Additionally, an upstream update of tzdata removed the 'old' SystemV
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
and earlier releases. Subsequently, these should be checked for using
the following:
[Test Case for releases <= 20.04 LTS]
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1948698/+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 1946096] Re: Support manual firmware upgrading for Foxconn and Quectel modems.
By investigating the mentioned patches directly, the existing behavior should not be changed: * The patch for Quectel EM160 4G There is only one patch, all changes are for the Quectel modems. * Patches for Foxconn T99W175 There are 5 patches, (patch#1): Modify the command line tool to get additional scan report for WWAN subsystem (patch#2): Move methods between 2 files (patch#3): Add more 15 seconds wait for the firmware upgrading (patch#4): Rename an existed carrier mapping configuration file for Foxconn modem (patch#5): Add a new carrier mapping configuration file for Foxconn modem From the code review, it's clear that changes only affect Foxconn and Quectel modems. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1946096 Title: Support manual firmware upgrading for Foxconn and Quectel modems. Status in OEM Priority Project: In Progress Status in modemmanager package in Ubuntu: New Bug description: [Impact] The modem certification requires that different modem firmware is used for different network carrier. This needs the firmware upgrading capability during the modem certification process. The modem manufacture vendors (Foxconn and Quectel) provided utilities to do modem's firmware upgrading manually.(LP#1943774, LP#1943780) These utilities are verified to be working when the recent versions(> v 1.18.2) of ModemManager are used with. To support manual firmware upgrading on the current Focal release which is using ModemManager v 1.16.6, we need to apply some patches from v 1.18.2. The requested upstream patches are listed as below: * for Quectel EM160 4G ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/83ac82470589a3672092a0ba0be855093b1cf5e2 * for Foxconn T99W175 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/21ae558fe3600c84b3ca7dcd9bf50a3ba576c7c9 **https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/76e700f4fd703f952208993330ab098305c13d6b ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/52bf2c641171ded9e617022f40497c8984520371 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/33e2b023ef01bea9da37ae2beb192f7d92bce47a ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/f72046701659073fbfa97516e155865647acb154 The firmware upgrading was verified using the patched ModemManager v 1.16.6 with the following 2 modems: * Foxconn SDX55 T99W175 5G sub6 PCIE Modem * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem [Test Plan] 1. Install the Ubuntu image. 2. Boot and login the system. 3. Prepare the modem’s firmware and install the firmware upgrading application provided by Foxconn and Quectel 4. Using the firmware upgrading application to upgrade the modem’s firmware 5. Verify if the modem’s firmware upgrading is successful 6. Reboot 7. Verify if the upgraded modem firmware is still working [Where problems could occur] The requested upstream patches are for these 2 specific modems. This should not affect existing generic functions and other modems. [Other Info] The firmware and the upgrading utilities can be downloaded from the following link: * LP#1943774 for Quectel modems * LP#1943780 for Foxconn modems To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1946096/+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 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2
The livecd-rootfs SRU for Bionic, Focal and Hirsute is currently blocked by another SRU in progress. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1917920 Title: magic-proxy broke with iptables 1.8.7-1ubuntu2 Status in launchpad-buildd: Invalid Status in iptables package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Invalid Status in iptables source package in Bionic: Invalid Status in livecd-rootfs source package in Bionic: New Status in lxd source package in Bionic: Invalid Status in iptables source package in Focal: Invalid Status in livecd-rootfs source package in Focal: New Status in lxd source package in Focal: Invalid Status in iptables source package in Hirsute: Invalid Status in livecd-rootfs source package in Hirsute: New Status in lxd source package in Hirsute: Invalid Bug description: [Impact] The fixes for this bug (including the fixes for LP:#1944906) need to be backported to hirsute, focal and bionic) to be able to re-enable the "repo-snapshot-stamp" feature for image builds. That feature is important to get consistent image builds (means the same set of packages included in the different images) when doing multiple builds (eg. for AWS, Azure and GCE). [Test Plan] - build a livecd-rootfs image with the changes for every series in a PPA - Do build an image with the livecd-rootfs from the PPA and enable the repo-snapshot-stamp feature - Check that the build did not fail or hang [Where problems could occur] The codepath that will be changed is only executed in livecd-rootfs if the repo-snapshot-stamp feature is enabled. And that feature is currently broken so it shouldn't be enabled anywhere. [Original description] when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic proxy stopped working in livecd-rootfs. It does very simple thing: iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon -j REDIRECT --to 8080 inside hirsute lxd container, with quite high privileges, in a bionic VM, running 4.15 kernel. With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound connectivity the very first http networking command after the above call would just hang indefinitely. However, if one does this instead: iptables -vv -t nat -S iptables-legacy -vv -t nat -S iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon -j REDIRECT --to 8080 somehow magically everything starts to work fine. weird. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+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 1846188] Re: Tooltips in Nautilus 3.34's burger menu are out of place (in Wayland sessions only)
** Tags added: impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1846188 Title: Tooltips in Nautilus 3.34's burger menu are out of place (in Wayland sessions only) Status in GTK+: Fix Released Status in gtk+3.0 package in Ubuntu: Fix Committed Status in nautilus package in Ubuntu: Invalid Bug description: Description: Ubuntu Eoan Ermine (development branch) Release: 19.10 In Nautilus, tooltips appear far to the left in the app menu. (Kazam and Peek were unable to record Nautilus) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1846188/+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 1946096] Re: Support manual firmware upgrading for Foxconn and Quectel modems.
> 3) Add a bunch of mappings from SIM->Carrier > Assuming (3) is not expected to change existing behaviour this looks like it would be acceptable under the hardware-enablement SRU policy. Agreed, but I would expect SRU information against every change being made, that would then receive separate SRU verification. This helps us mitigate risk by 1) actually considering each change in the first place, rather than it "slipping past" review; and 2) reducing the potential number of SRUs, and therefore user time, bandwidth and regression risk, by actually verifying that things are being changed as expected so we don't have to do it twice. I'm disappointed that this has now gone through two SRU review rounds, and it is Chris who has extracted the actual nature of the changes that you are looking to land here. This detail should have been laid out in the bug (or multiple bugs) and in the SRU information in the first place. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1946096 Title: Support manual firmware upgrading for Foxconn and Quectel modems. Status in OEM Priority Project: In Progress Status in modemmanager package in Ubuntu: New Bug description: [Impact] The modem certification requires that different modem firmware is used for different network carrier. This needs the firmware upgrading capability during the modem certification process. The modem manufacture vendors (Foxconn and Quectel) provided utilities to do modem's firmware upgrading manually.(LP#1943774, LP#1943780) These utilities are verified to be working when the recent versions(> v 1.18.2) of ModemManager are used with. To support manual firmware upgrading on the current Focal release which is using ModemManager v 1.16.6, we need to apply some patches from v 1.18.2. The requested upstream patches are listed as below: * for Quectel EM160 4G ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/83ac82470589a3672092a0ba0be855093b1cf5e2 * for Foxconn T99W175 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/21ae558fe3600c84b3ca7dcd9bf50a3ba576c7c9 **https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/76e700f4fd703f952208993330ab098305c13d6b ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/52bf2c641171ded9e617022f40497c8984520371 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/33e2b023ef01bea9da37ae2beb192f7d92bce47a ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/f72046701659073fbfa97516e155865647acb154 The firmware upgrading was verified using the patched ModemManager v 1.16.6 with the following 2 modems: * Foxconn SDX55 T99W175 5G sub6 PCIE Modem * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem [Test Plan] 1. Install the Ubuntu image. 2. Boot and login the system. 3. Prepare the modem’s firmware and install the firmware upgrading application provided by Foxconn and Quectel 4. Using the firmware upgrading application to upgrade the modem’s firmware 5. Verify if the modem’s firmware upgrading is successful 6. Reboot 7. Verify if the upgraded modem firmware is still working [Where problems could occur] The requested upstream patches are for these 2 specific modems. This should not affect existing generic functions and other modems. [Other Info] The firmware and the upgrading utilities can be downloaded from the following link: * LP#1943774 for Quectel modems * LP#1943780 for Foxconn modems To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1946096/+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 1946096] Re: Support manual firmware upgrading for Foxconn and Quectel modems.
How do you intend to verify that (3) has worked correctly? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1946096 Title: Support manual firmware upgrading for Foxconn and Quectel modems. Status in OEM Priority Project: In Progress Status in modemmanager package in Ubuntu: New Bug description: [Impact] The modem certification requires that different modem firmware is used for different network carrier. This needs the firmware upgrading capability during the modem certification process. The modem manufacture vendors (Foxconn and Quectel) provided utilities to do modem's firmware upgrading manually.(LP#1943774, LP#1943780) These utilities are verified to be working when the recent versions(> v 1.18.2) of ModemManager are used with. To support manual firmware upgrading on the current Focal release which is using ModemManager v 1.16.6, we need to apply some patches from v 1.18.2. The requested upstream patches are listed as below: * for Quectel EM160 4G ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/83ac82470589a3672092a0ba0be855093b1cf5e2 * for Foxconn T99W175 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/21ae558fe3600c84b3ca7dcd9bf50a3ba576c7c9 **https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/76e700f4fd703f952208993330ab098305c13d6b ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/52bf2c641171ded9e617022f40497c8984520371 ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/33e2b023ef01bea9da37ae2beb192f7d92bce47a ** https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/f72046701659073fbfa97516e155865647acb154 The firmware upgrading was verified using the patched ModemManager v 1.16.6 with the following 2 modems: * Foxconn SDX55 T99W175 5G sub6 PCIE Modem * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem [Test Plan] 1. Install the Ubuntu image. 2. Boot and login the system. 3. Prepare the modem’s firmware and install the firmware upgrading application provided by Foxconn and Quectel 4. Using the firmware upgrading application to upgrade the modem’s firmware 5. Verify if the modem’s firmware upgrading is successful 6. Reboot 7. Verify if the upgraded modem firmware is still working [Where problems could occur] The requested upstream patches are for these 2 specific modems. This should not affect existing generic functions and other modems. [Other Info] The firmware and the upgrading utilities can be downloaded from the following link: * LP#1943774 for Quectel modems * LP#1943780 for Foxconn modems To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1946096/+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 1892559] Re: [MIR] ccid opensc pcsc-lite
I've reported the lack of symbols to Debian on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997932 with a patch now ** Bug watch added: Debian Bug tracker #997932 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997932 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1892559 Title: [MIR] ccid opensc pcsc-lite Status in ccid package in Ubuntu: New Status in opensc package in Ubuntu: Incomplete Status in pam-pkcs11 package in Ubuntu: Invalid Status in pcsc-lite package in Ubuntu: New Status in pcsc-perl package in Ubuntu: Invalid Status in pcsc-tools package in Ubuntu: Invalid Bug description: ==> ccid <== [Availability] ccid is in universe, and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs for ccid are listed in our database. Doesn't appear to bind to a socket. No privileged executables, but does have udev rules. Probably needs a security review. [Quality assurance] No test suite. Does require odd hardware that we'll probably need to buy. I don't see debconf questions. ccid is well maintained in Debian by upstream author. One open wishlist bug in BTS, harmless. One open bug in launchpad, not security, but looks very frustrating for the users. The upstream author was engaged but it never reached resolution. https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465 Has a debian/watch file. Quilt packaging. P: ccid source: no-dep5-copyright P: ccid source: package-uses-experimental-debhelper-compat-version 13 [Dependencies] Minimal dependencies, in main [Standards compliance] Appears to satisfy FHS and Debian policy [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] ccid provides drivers to interact with usb-connected smart card readers. ==> libpam-pkcs11 <== [Availability] Source package pam-pkcs11 is in universe and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs in our database. Doesn't appear to bind to sockets. No privileged executables (but is a PAM module). As a PAM module this will require a security review. [Quality assurance] The package does not call pam-auth-update in its postinst #1650366 Does not ask questions during install. One Ubuntu bug claims very poor behaviour if a card isn't plugged in. No Debian bugs. Occasional updates in Debian by long-term maintainer. Does require odd hardware that we'll probably need to buy. Does not appear to run tests during build. Has scary warnings in the build logs. Has a debian/watch file. Ancient standards version; other smaller lintian messages, mostly documentation problems. Quilt packaging. [Dependencies] Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1 All are in main. [Standards compliance] The package does not call pam-auth-update in its postinst #1650366 Otherwise looks to conform to FHS and Debian policies [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] This PAM module can use CRLs and full-chain verification of certificates. It can also do LDAP, AD, and Kerberos username mapping. ==> libpcsc-perl <== [Availability] Source package pcsc-perl is in universe, builds for all architectures, plus i386 [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] There are no cves for pcsc-perl in our database. No privileged executables. Doesn't appear to bind to sockets. Probably needs a security review. [Quality assurance] Library package not intended to be used directly. No debconf questions. No bugs in Debian. No bugs in Ubuntu. Does require odd hardware that we'll probably need to buy. Tests exist, not run during the build; probably can't run during the build. Includes debian/watch file. A handful of lintian issues Quilt packaging. [Dependencies] libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0. All are in main. [Standards compliance] One oddity, Card.pod is stored in /usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/ Many other perl packages have .pod files in these directory trees so maybe it's fine, but it seems funny all the same. Otherwise appears to satisfy FHS and Debian policy. [Maintenance] The desktop team will subscribe to bugs,
[Touch-packages] [Bug 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy)
I'm surprised to see Replaces without a Breaks, and further for the Replaces to be unversioned. This doesn't match one of the cases listed at https://wiki.debian.org/PackageTransition, and https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 explains why usually a Breaks is also required. Since I'm not sure this is correct, I'm reluctant to accept it on review. I'm not sure it's necessarily wrong, either. I'll ping Steve for an opinion. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute and Focal2Jammy) Status in libsignon-glib package in Ubuntu: Fix Released Status in libsignon-glib source package in Hirsute: In Progress Status in libsignon-glib source package in Impish: In Progress Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. [Test Case] This can be simply tested with a focal schroot: 1) apt-get install vim libsignon-glib-dev 2) edit /etc/apt/sources.list replacing focal with hirsute 3) apt-get update 4) apt-get install libsignon-glib-dev With the version of libsignon-glib-dev from -proposed you'll no longer receive the 'dpkg: error' from below. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. [Regression Potential] We are adding a replaces with gir1.2-signon-1.0 so anything that depends on that package would be broken but given that that package is no longer available after focal that seems fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1947677] Re: Colemak keyboard layout's left-hand backspace is also acting as Caps Lock
I have since found that executing in Terminal, the command 횡횖횘획횖횊횙 -횎 "회횕횎횊횛 홻횘회횔" is a temporary workaround to fix this behaviour; however, I would definitely think this issue should be fixed so it works out-of-the-box for new users. It's a very problematic behaviour for one's primary backspace to be also toggling caps lock, affecting daily typing. -- 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/1947677 Title: Colemak keyboard layout's left-hand backspace is also acting as Caps Lock Status in xorg package in Ubuntu: New Bug description: I have installed Ubuntu with the default English (US) Qwerty keyboard layout and I added the English (Australia) Colemak keyboard layout through the Settings app (as per the screenshot attached). This is for the in-built laptop keyboard on the Lenovo ThinkPad X1 Yoga Touch. The bug is that the CapsLock key, which is meant to be remapped to a Backspace key on the Colemak keyboard layout, acts as both the CapsLock AND the Backspace, when the Colemak keyboard layout is active. This means that backspacing a single time deletes a single character AND also toggles Caps Lock. The expected behaviour is that the key acts only as Backspace when the Colemak keyboard layout is active. The output of 횡횙횛횘횙 -횛횘횘횝 | 횐횛횎횙 횇홺홱 is _횇홺홱_횁횄홻홴횂_홽홰홼홴횂(횂횃횁홸홽홶) = "횎횟획횎횟", "횙회ퟷퟶퟻ", "횞횜,횞횜,횞횜", ",회횘횕횎횖횊횔,", "" I hope a fix can be found soon :) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.11.0-38.42~20.04.1-generic 5.11.22 Uname: Linux 5.11.0-38-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.20 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Oct 19 17:34:44 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 620 [17aa:224e] InstallationDate: Installed on 2021-10-09 (9 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) MachineType: LENOVO 20JDA00CAU ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.11.0-38-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/17/2021 dmi.bios.release: 1.41 dmi.bios.vendor: LENOVO dmi.bios.version: N1NET54W (1.41 ) dmi.board.asset.tag: Not Available dmi.board.name: 20JDA00CAU dmi.board.vendor: LENOVO dmi.board.version: SDK0K17763 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 31 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.19 dmi.modalias: dmi:bvnLENOVO:bvrN1NET54W(1.41):bd08/17/2021:br1.41:efr1.19:svnLENOVO:pn20JDA00CAU:pvrThinkPadX1Yoga2nd:skuLENOVO_MT_20JD_BU_Think_FM_ThinkPad:rvnLENOVO:rn20JDA00CAU:rvrSDK0K17763WIN:cvnLENOVO:ct31:cvrNone: dmi.product.family: ThinkPad dmi.product.name: 20JDA00CAU dmi.product.sku: LENOVO_MT_20JD_BU_Think_FM_ThinkPad dmi.product.version: ThinkPad X1 Yoga 2nd dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.105-3~20.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.3 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-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/1947677/+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 1891338] Re: apparmor misconfigured for evince
** Changed in: evince (Ubuntu) Importance: Undecided => Low ** Changed in: evince (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1891338 Title: apparmor misconfigured for evince Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Committed Bug description: On a fully up to date xubuntu 20-04 system, when i run evince and click on a link, it fails to follow that link in my browser. This kind of thing happens when you are reading a technical paper and want to follow one of the references and click on the doi or url. When i click on the link i get a box that i cannot copy from that says: Failed to launch preferred application for category "WebBrowser". Failed to execute child process "/usr/lib/x86_64-linux- gnu/xfce4/exo-2/exo-helper-2"(Permission denied). Did I say that it is annoying that i could not copy the text in this box!! The output of the ldd command you asked for is attached. I should also point out that this worked fine under xubuntu 18.04. I had originally posted this as an additional comment on https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1869159?comments=all but https://launchpad.net/~seb128 said that I should submit this as a separate bug because this is likely an apparmor configuration problem that is similar to the ancient bug https://bugs.launchpad.net/bugs/987578. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1891338/+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 1942940] Re: Hover text in wrong place
*** This bug is a duplicate of bug 1846188 *** https://bugs.launchpad.net/bugs/1846188 ** This bug has been marked a duplicate of bug 1846188 Tooltips in Nautilus 3.34's burger menu are out of place (in Wayland sessions only) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1942940 Title: Hover text in wrong place Status in GTK+: Unknown Status in gtk+3.0 package in Ubuntu: Triaged Bug description: Open Nautilus, click the hamburger button, hover over the "New tab/window/folder" icons. The popup hover text is way over to the LHS of the Nautilus window. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: nautilus 1:3.38.2-1ubuntu2 ProcVersionSignature: Ubuntu 5.11.0-34.36-generic 5.11.22 Uname: Linux 5.11.0-34-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Sep 8 10:53:38 2021 GsettingsChanges: b'org.gnome.nautilus.window-state' b'sidebar-width' b'303' b'org.gnome.nautilus.window-state' b'initial-size' b'(999, 784)' b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" InstallationDate: Installed on 2019-04-27 (864 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) ProcEnviron: LANGUAGE=en_NZ:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_NZ.UTF-8 SHELL=/bin/bash SourcePackage: nautilus UpgradeStatus: Upgraded to hirsute on 2021-07-13 (56 days ago) usr_lib_nautilus: evince40.1-1 file-roller 3.38.1-1 nautilus-extension-gnome-terminal 3.38.1-1ubuntu1 nautilus-share0.7.3-2ubuntu3 To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1942940/+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 1846188] Re: Tooltips in Nautilus 3.34's burger menu are out of place (in Wayland sessions only)
** Tags added: desktop-lts-wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1846188 Title: Tooltips in Nautilus 3.34's burger menu are out of place (in Wayland sessions only) Status in GTK+: Fix Released Status in gtk+3.0 package in Ubuntu: Fix Committed Status in nautilus package in Ubuntu: Invalid Bug description: Description: Ubuntu Eoan Ermine (development branch) Release: 19.10 In Nautilus, tooltips appear far to the left in the app menu. (Kazam and Peek were unable to record Nautilus) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1846188/+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 1928393] Re: linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0] retry page fault"
Hi. I'm picking up this ticket from Seth. Reading through the history it seems it's still an open issue? My understanding is that upstream 'fixed' this by reverting fw blobs in version 20210818. I can produce a linux-firmware test package for hirsute 20.04 with these reverts if necessary. Just let me know. ** Changed in: linux-firmware (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1928393 Title: linux-firmware 1.197 causes kernel to report error "amdgpu: [gfxhub0] retry page fault" Status in amd: New Status in linux-firmware package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Bug description: After upgrading linux-firmware from 1.190.5 to 1.197 (as part of the upgrade from Ubuntu 20.10 to 21.04), I started experiencing frequent and severe GPU instability. When this happens, I see this error in dmesg: [20061.061069] amdgpu :03:00.0: amdgpu: [gfxhub0] retry page fault (src_id:0 ring:0 vmid:1 pasid:32769, for process Xorg pid 1141 thread Xorg:cs0 pid 1236) [20061.061103] amdgpu :03:00.0: amdgpu: in page starting at address 0x80401000 from client 27 [20061.061135] amdgpu :03:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [20061.061147] amdgpu :03:00.0: amdgpu: Faulty UTCL2 client ID: TCP (0x8) [20061.061157] amdgpu :03:00.0: amdgpu: MORE_FAULTS: 0x1 [20061.061167] amdgpu :03:00.0: amdgpu: WALKER_ERROR: 0x0 [20061.061174] amdgpu :03:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [20061.061183] amdgpu :03:00.0: amdgpu: MAPPING_ERROR: 0x0 [20061.061189] amdgpu :03:00.0: amdgpu: RW: 0x0 I'll attach a couple of full dmesgs that I collected. Many of the times when this happens, the screen and keyboard freeze irreversibly (I tried waiting for more than 30 minutes, but it doesn't help). I can still log in via ssh though. When there's no freeze, I can continue using the computer normally, but the laptop fans keep running are always running and the battery depletes fast. There's probably something on a permanent loop either in the kernel or in the GPU. This bug happens several times a day, rendering the machine so unstable as to be almost unusable. It is a severe regression and I'm aghast that it passed AMD's Quality Assurance. After downgrading back to linux-firmware 1.190.5, the machine is back to the previous, mostly-reliable state. Which is to say, this bug is gone, I'm just left with the other amdgpu suspend bug I've learned to live with since I bought this computer. Please revert the amdgpu firmware in this package as soon as possible. This is unbearable. Relevant information: Ubuntu version: 21.04 Linux kernel: 5.11.0-17-generic x86_64 CPU model: AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx GPU: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c1) Laptop model: Lenovo Ideapad S145 To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1928393/+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 1921518] Re: OpenSSL "double free" error
While trying to understand why a fix in PKA that guards against multiple destroys (https://github.com/Mellanox/pka/pull/37/files) didn't bypass this issue, I found the following. bind() operation of engines is expected to populate the pmeths and ameths of an existing engine (https://github.com/gost- engine/engine/blob/df3ead272bd2019f98d16e6787f5df51556c0603/gost_eng.c#L375, https://github.com/Mellanox/pka/blob/master/engine/e_bluefield.c#L1615). This means that the engine uses EVP_PKEY_meth_new (for instance) as part of this registration. However, on teardown, OpenSSL's engine_free_util() is invoking engine_pkey_meths_free() and engine_pkey_asn1_meths_free(). Both of which iterate the list of registered methods, and invoke EVP_PKEY_meth_free() on each on of them. Only after OpenSSL freed these methods it calls the engine's destroy() method which allows the registered engine to do its own cleanup. As long as this design is used, an engine using pkey methods can't protect itself against multiple destroy operations, because OpenSSL is the one freeing it's methods and there isn't much the engine can do about it. For future versions, it might be recommended to update this API and grant the engine the ownership on clearing up the memory that it allocated on the first place. -- 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/1921518 Title: OpenSSL "double free" error Status in openssl package in Ubuntu: Incomplete Status in openssl source package in Focal: Incomplete Bug description: "double free" error is seen when using curl utility. Error is from libcrypto.so which is part of the OpenSSL package. This happens only when OpenSSL is configured to use a dynamic engine. OpenSSL version is 1.1.1f The issue is not encountered if http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead. OpenSSL can be configured to use a dynamic engine by editing the default openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu systems. On Bluefield systems, config diff to enable PKA dynamic engine, is as below: +openssl_conf = conf_section + # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section= new_oids +[ conf_section ] +engines = engine_section + +[ engine_section ] +bf = bf_section + +[ bf_section ] +engine_id=pka +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so +init=0 + engine_id above refers to dynamic engine name/identifier. dynamic_path points to the .so file for the dynamic engine. # curl -O https://tpo.pe/pathogen.vim double free or corruption (out) Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1948904] [NEW] Installed systemd package post-installation script subprocess returned error exit status 127
Public bug reported: The package systemd started giving error after upgrade to 21.10 from 21.04. Setting up systemd (248.3-1ubuntu8) ... systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-247.so: cannot open shared object file: No such file or directory dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) When I tried to force reinstall systemd it gives following error. Internal Error, No file name for systemd:amd64 ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: systemd 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 12:00:49 2021 InstallationDate: Installed on 2018-11-21 (1070 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 27c6:55a4 Shenzhen Goodix Technology Co.,Ltd. Goodix FingerPrint Device Bus 001 Device 002: ID 13d3:5415 IMC Networks Integrated Camera Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 1M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M |__ Port 8: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M |__ Port 8: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M MachineType: LENOVO 20RAS0D800 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-20-generic root=UUID=b69e3e1e-fa29-46b4-8ec8-c6cee754774b ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. UpgradeStatus: Upgraded to impish on 2021-10-19 (7 days ago) dmi.bios.date: 09/14/2020 dmi.bios.release: 1.14 dmi.bios.vendor: LENOVO dmi.bios.version: R16ET28W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20RAS0D800 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.11 dmi.modalias: dmi:bvnLENOVO:bvrR16ET28W(1.14):bd09/14/2020:br1.14:efr1.11:svnLENOVO:pn20RAS0D800:pvrThinkPadE14:skuLENOVO_MT_20RA_BU_SMB_FM_ThinkPadE14:rvnLENOVO:rn20RAS0D800:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad E14 dmi.product.name: 20RAS0D800 dmi.product.sku: LENOVO_MT_20RA_BU_SMB_FM_ThinkPad E14 dmi.product.version: ThinkPad E14 dmi.sys.vendor: LENOVO ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish third-party-packages -- 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/1948904 Title: Installed systemd package post-installation script subprocess returned error exit status 127 Status in systemd package in Ubuntu: New Bug description: The package systemd started giving error after upgrade to 21.10 from 21.04. Setting up systemd (248.3-1ubuntu8) ... systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-247.so: cannot open shared object file: No such file or directory dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) When I tried to force reinstall systemd it gives following error. Internal Error, No file name for systemd:amd64 ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: systemd 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Oct 27 12:00:49 2021 InstallationDate: Installed on 2018-11-21 (1070 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 27c6:55a4 Shenzhen Goodix Technology
