[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
3.0.6 include this fix. -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Triaged Status in openssl source package in Jammy: Triaged Status in openssl source package in Kinetic: Triaged Bug description: https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 1994912] [NEW] Custom image is not refreshed on new calls to notify-send
Public bug reported: When using a custom image with the notify-send command (e.g. notify-send -i /home//images/test.png "test") the image, once loaded, is not refreshed. This can be tested by running a command such as the example one, then overwriting "current.png" with a different image, and running the command again. The images shown in the two notifications will both be the original image. I would expect the second image to be different. Example "code": cd home//images/ cp image1.png test.png notify-send -i /home//images/test.png "test" cp image2.png test.png notify-send -i /home//images/test.png "test" Of note is that this appears to affect both the notification shown on an unlocked desktop and one shown on the lock screen; however, these can be "stuck" on different versions of the image, although they will remain stuck. That is, the notification bubble shown on the lock screen will always shown one version of an image, and the desktop notification will always show one version of the image, but these are not necessarily the same image. So a notification generated with "sleep 5; " (and you locking your desktop in the 5 seconds) will show one image, and then when you unlock your desktop the same notification can be a different image. Ubuntu 20.04.04 LTS GNOME 3.36.8 libnotify-bin 0.7.9-1ubuntu2 notify-osd notification-daemon ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libnotify-bin 0.7.9-1ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-52.58~20.04.1-generic 5.15.60 Uname: Linux 5.15.0-52-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Oct 26 21:02:54 2022 InstallationDate: Installed on 2022-04-06 (204 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libnotify UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: libnotify (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal third-party-packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnotify in Ubuntu. https://bugs.launchpad.net/bugs/1994912 Title: Custom image is not refreshed on new calls to notify-send Status in libnotify package in Ubuntu: New Bug description: When using a custom image with the notify-send command (e.g. notify- send -i /home//images/test.png "test") the image, once loaded, is not refreshed. This can be tested by running a command such as the example one, then overwriting "current.png" with a different image, and running the command again. The images shown in the two notifications will both be the original image. I would expect the second image to be different. Example "code": cd home//images/ cp image1.png test.png notify-send -i /home//images/test.png "test" cp image2.png test.png notify-send -i /home//images/test.png "test" Of note is that this appears to affect both the notification shown on an unlocked desktop and one shown on the lock screen; however, these can be "stuck" on different versions of the image, although they will remain stuck. That is, the notification bubble shown on the lock screen will always shown one version of an image, and the desktop notification will always show one version of the image, but these are not necessarily the same image. So a notification generated with "sleep 5; " (and you locking your desktop in the 5 seconds) will show one image, and then when you unlock your desktop the same notification can be a different image. Ubuntu 20.04.04 LTS GNOME 3.36.8 libnotify-bin 0.7.9-1ubuntu2 notify-osd notification-daemon ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libnotify-bin 0.7.9-1ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-52.58~20.04.1-generic 5.15.60 Uname: Linux 5.15.0-52-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Oct 26 21:02:54 2022 InstallationDate: Installed on 2022-04-06 (204 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libnotify UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1994912/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing
Typo? I'd expect 'Just "w" is enough' ;-) -- 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/1993572 Title: samba profile: missing rule for mkdir /var/cache/samba/printing Status in apparmor package in Ubuntu: New Bug description: After the fix for bug #1990692, one more rule is needed it seems. I put all samba profiles in enforce mode, and when I ran that final rpcclient command, got an error and an apparmor denied message: Prep: sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra sudo apt install samba smbclient cups cups-client Set a password for the samba "root" user: printf "root\nroot\n" | sudo smbpasswd -a root Create a fake printer: sudo lpadmin -p testprinter -E -v /dev/null Check it's there: sudo lpstat -l -p testprinter $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2' cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error NT_STATUS_CONNECTION_DISCONNECTED do_cmd: Could not initialise spoolss. Error was NT_STATUS_CONNECTION_DISCONNECTED [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342): apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd- k-samba-apparmor_" profile="samba-rpcd- spoolss" name="/var/cache/samba/printing/" pid=129107 comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100 ouid=100 And indeed, that directory wasn't created: $ l /var/cache/samba/printing ls: cannot access '/var/cache/samba/printing': No such file or directory $ l /var/cache/samba/ total 16K drwxr-xr-x 1 root root 48 Oct 19 17:42 . drwxr-xr-x 1 root root 170 Oct 19 17:41 .. -rw-r--r-- 1 root root 166 Oct 19 17:42 browse.dat -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1993869] Re: openssh-server cannot listen or bind to anything other than :::2 after upgrading to 22.10 from 22.04
You can close this. I did an upgrade from ubuntu 18.04 since I initially upgraded to 22.04 from this version, and openssh-server's sockets didn't break the install. If the error happened it's either related to the Ubuntu 18.04 install/image that was provided by my host or some freak corruption. If I had touched anything related to systemd's openssh-server but forgot about it, it would have been the service and a .d folder in /etc/systemd/system -> https://i.imgur.com/eTRBEmc.png I joined the dist-upgrade folder with the two ssh.service.d and ssh.socket.d folder and override files that were created during the upgrade. ** Attachment added: "dist-upgrade.zip" https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993869/+attachment/5627085/+files/dist-upgrade.zip -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1993869 Title: openssh-server cannot listen or bind to anything other than :::2 after upgrading to 22.10 from 22.04 Status in openssh package in Ubuntu: Incomplete Bug description: This is a bug report to separate the second issue that was reported in this bug report: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993478 There's an issue after upgrading to 22.10 from 22.04 that prevents opensshd from listening to anything other than :::2. I already commented in the bug report I linked, so I'll just copy/paste and add some details. I guess. The issue is that after upgrading, sshd doesn't use the Listen port or ListenAddress config from the sshd_config file or any custom config file that was in the sshd_config.d drop in folder anymore. Other drop in settings from sshd.config.d seem to be applied normally, the issue seem to be only for IP binding and custom ports. If I change Accept=no by Accept=yes in ssh.socket and reloads the socket unit, I can start sshd on a different port and I can also bind the IP to something else than :: There's an issue still, an instance of sshd is still listening to :::22 that is not started by SSHD but by init. root@ubuntulocal:~# netstat -antp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 568/vsftpd tcp 0 0 0.0.0.0:622 0.0.0.0:* LISTEN 571/sshd: /usr/sbin tcp 0 272 192.168.1.225:622 192.168.1.220:2473 ESTABLISHED 1027/sshd: root@pts tcp6 0 0 :::22 :::* LISTEN 1/init If I reboot after changing this no to yes in ssh.socket does not survive a reboot and fails to load sshd with a "Failed to queue service startup job" error. Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed with result 'resources'. I had to mask/stop the sshd.socket unit and create a custom sshd service in /etc/systemd/system to be able start sshd on a custom port and IP. chris@ubuntulocal:~$ systemctl status ssh.socket ● ssh.socket - OpenBSD Secure Shell server socket Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled) Active: active (running) since Fri 2022-10-21 23:08:09 UTC; 1min 24s ago Until: Fri 2022-10-21 23:08:09 UTC; 1min 24s ago Triggers: ● ssh.service Listen: [::]:22 (Stream) Tasks: 0 (limit: 18899) Memory: 4.0K CPU: 418us CGroup: /system.slice/ssh.socket To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993869/+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 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing
/var/cache/samba/printing/ w, # without r, Just "r" was enough indeed! -- 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/1993572 Title: samba profile: missing rule for mkdir /var/cache/samba/printing Status in apparmor package in Ubuntu: New Bug description: After the fix for bug #1990692, one more rule is needed it seems. I put all samba profiles in enforce mode, and when I ran that final rpcclient command, got an error and an apparmor denied message: Prep: sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra sudo apt install samba smbclient cups cups-client Set a password for the samba "root" user: printf "root\nroot\n" | sudo smbpasswd -a root Create a fake printer: sudo lpadmin -p testprinter -E -v /dev/null Check it's there: sudo lpstat -l -p testprinter $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2' cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error NT_STATUS_CONNECTION_DISCONNECTED do_cmd: Could not initialise spoolss. Error was NT_STATUS_CONNECTION_DISCONNECTED [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342): apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd- k-samba-apparmor_" profile="samba-rpcd- spoolss" name="/var/cache/samba/printing/" pid=129107 comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100 ouid=100 And indeed, that directory wasn't created: $ l /var/cache/samba/printing ls: cannot access '/var/cache/samba/printing': No such file or directory $ l /var/cache/samba/ total 16K drwxr-xr-x 1 root root 48 Oct 19 17:42 . drwxr-xr-x 1 root root 170 Oct 19 17:41 .. -rw-r--r-- 1 root root 166 Oct 19 17:42 browse.dat -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1
The attachment "openssh_9.0p1-1ubuntu8.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1993478 Title: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1 Status in openssh package in Ubuntu: Triaged Status in openssh source package in Kinetic: Triaged Bug description: [Impact] Users with /etc/ssh/sshd_config's that contain ListenAddress entries with the port specified will not be migrated to socket-activated ssh correctly, or may be migrated when they should not be (e.g. if ListenAddress, with a port number, is specified more than once). This leaves users with a broken sshd configuration. [Test Plan] There are 4 tests that should be used to verify the fix: 1. Upgrade to Kinetic with just one ListenAddress entry, which specifies port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, ssh.socket will be active/listening, and /etc/systemd/system/ssh.socket.d/addresses.conf will contain the following: [Socket] ListenStream= ListenStream=0.0.0.0:1234 2. Upgrade to Kinetic with multiple ListenAddress entries, each specifying port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, migration will be attempted despite the multiple ListenAddress options, and ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, the ListenAddress option will be parsed correctly, and migration will not be attempted. 3. On a Kinetic system which was migrated, but with errors (e.g. test case #1, prior to being patched), installing the new package should correct the ssh.socket configuration. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable -proposed before the upgrade. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. * The ssh.socket configuration should be fixed, and /etc/systemd/system/ssh.socket.d/addresses.conf should contain: [Socket] ListenStream= ListenStream=0.0.0.0:1234 4. On a Kinetic system which was incorrectly migrated to ssh socket activation (e.g. test case #2, prior to being patched), installing the new package reverts to the previous behavior. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable
[Touch-packages] [Bug 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing
** Description changed: After the fix for bug #1990692, one more rule is needed it seems. I put all samba profiles in enforce mode, and when I ran that final - command, got an error and an apparmor denied message: + rpcclient command, got an error and an apparmor denied message: + + Prep: + sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra + sudo apt install samba smbclient cups cups-client + + Set a password for the samba "root" user: + printf "root\nroot\n" | sudo smbpasswd -a root + + Create a fake printer: + sudo lpadmin -p testprinter -E -v /dev/null + + Check it's there: + sudo lpstat -l -p testprinter $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2' cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error NT_STATUS_CONNECTION_DISCONNECTED do_cmd: Could not initialise spoolss. Error was NT_STATUS_CONNECTION_DISCONNECTED [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342): apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd-k- samba-apparmor_" profile="samba-rpcd-spoolss" name="/var/cache/samba/printing/" pid=129107 comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100 ouid=100 And indeed, that directory wasn't created: $ l /var/cache/samba/printing ls: cannot access '/var/cache/samba/printing': No such file or directory $ l /var/cache/samba/ total 16K drwxr-xr-x 1 root root 48 Oct 19 17:42 . drwxr-xr-x 1 root root 170 Oct 19 17:41 .. -rw-r--r-- 1 root root 166 Oct 19 17:42 browse.dat -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb -- 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/1993572 Title: samba profile: missing rule for mkdir /var/cache/samba/printing Status in apparmor package in Ubuntu: New Bug description: After the fix for bug #1990692, one more rule is needed it seems. I put all samba profiles in enforce mode, and when I ran that final rpcclient command, got an error and an apparmor denied message: Prep: sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra sudo apt install samba smbclient cups cups-client Set a password for the samba "root" user: printf "root\nroot\n" | sudo smbpasswd -a root Create a fake printer: sudo lpadmin -p testprinter -E -v /dev/null Check it's there: sudo lpstat -l -p testprinter $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2' cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error NT_STATUS_CONNECTION_DISCONNECTED do_cmd: Could not initialise spoolss. Error was NT_STATUS_CONNECTION_DISCONNECTED [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342): apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd- k-samba-apparmor_" profile="samba-rpcd- spoolss" name="/var/cache/samba/printing/" pid=129107 comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100 ouid=100 And indeed, that directory wasn't created: $ l /var/cache/samba/printing ls: cannot access '/var/cache/samba/printing': No such file or directory $ l /var/cache/samba/ total 16K drwxr-xr-x 1 root root 48 Oct 19 17:42 . drwxr-xr-x 1 root root 170 Oct 19 17:41 .. -rw-r--r-- 1 root root 166 Oct 19 17:42 browse.dat -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1994077] Re: GPU fan goes at 100% during mild-moderate activity, disregarding built fan curve or custom fan curve
seems like a hardware problem affecting as it affects only one of the two GPU fans. I think that this bug report can be disregarded. ** Changed in: xorg (Ubuntu) Status: New => Invalid -- 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/1994077 Title: GPU fan goes at 100% during mild-moderate activity, disregarding built fan curve or custom fan curve Status in xorg package in Ubuntu: Invalid Bug description: Issue with graphics card fan running at max RPM if either cpu or gpu are put under slight stress. Usually when graphics card temp goes above 50 degrees celsius, but also if the CPU is performing some intensive work. This has started ever since upgrading to Ubuntu 22.04. The actual GPU fan speed reported is sometimes misreported during these errors, and does not respond to manual control through CoreCTRL or via command-line, but it is definitely the GPU fan which is making the noise. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 Uname: Linux 6.1.0-060100rc1-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: CasperMD5CheckResult: unknown CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Oct 24 22:52:32 2022 DistUpgraded: 2022-09-11 18:48:47,235 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev c7) (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [174b:e353] InstallationDate: Installed on 2018-03-19 (1680 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) MachineType: Micro-Star International Co., Ltd. MS-7A33 ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-6.1.0-060100rc1-generic root=UUID=49a0c4fb-2e67-4829-992f-626d1d40dc33 ro rootflags=subvol=@ resume=UUID=0841c49c-0031-4984-a508-c94b1cd49dd3 amdgpu.vm_fragment_size=9 amdgpu.ppfeaturemask=0x SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to jammy on 2022-09-11 (43 days ago) dmi.bios.date: 05/25/2022 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 5.L3 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: X370 GAMING PLUS (MS-7A33) dmi.board.vendor: MSI dmi.board.version: 3.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 3.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr5.L3:bd05/25/2022:br5.17:svnMicro-StarInternationalCo.,Ltd.:pnMS-7A33:pvr3.0:rvnMSI:rnX370GAMINGPLUS(MS-7A33):rvr3.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr3.0:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7A33 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 3.0 dmi.sys.vendor: Micro-Star International Co., Ltd. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.2~kisak1~j version.libgl1-mesa-glx: libgl1-mesa-glx 22.2.2~kisak1~j version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 xserver.bootTime: Thu Apr 15 23:58:44 2021 xserver.configfile: default xserver.devices: xserver.logfile: /var/log/Xorg.0.log xserver.version: 2:1.20.9-2ubuntu1.2~20.04.2 xserver.video_driver: amdgpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1994077/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
name="apparmor/.null" is used to remove access to an already open file that is being inherited and should no longer be available. Whether because policy doesn't allow it. AppArmor can't just close the file because the fd for the file might have meaning and closing the file would free up the fd slot and it could then be filled by a new open which could cause all kinds of weird issues. lxd does auto generate profiles. So that is a good bet as to what is happening. -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1994697] Re: 1400x900 (3:2) resolution mismatch
** Description changed: - The listed resolution 1400x900 (3:2) it's not correct: my monitor is 16:10 and I can see black bars. - I suppose the real resolution is 1400x960 (3:2), but the actual 1400x900 (16:10) is missing. + The listed resolution 1440x900 (3:2) it's not correct: my monitor is 16:10 and I can see black bars. + I suppose the real resolution is 1440x960 (3:2), but the actual 1440x900 (16:10) is missing. I updated some packages today and the issue came after reboot: 2022-10-26 16:48:06 upgrade google-chrome-stable:amd64 106.0.5249.119-1 107.0.5304.68-1 2022-10-26 16:48:14 upgrade tzdata:all 2022c-0ubuntu0.22.04.0 2022e-0ubuntu0.22.04.0 2022-10-26 16:48:14 upgrade alsa-ucm-conf:all 1.2.6.3-1ubuntu1 1.2.6.3-1ubuntu1.1 2022-10-26 16:48:14 upgrade docker-ce-cli:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:18 upgrade docker-ce:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:20 upgrade docker-ce-rootless-extras:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:20 upgrade docker-compose-plugin:amd64 2.12.0~ubuntu-jammy 2.12.2~ubuntu-jammy 2022-10-26 16:48:21 upgrade docker-scan-plugin:amd64 0.17.0~ubuntu-jammy 0.21.0~ubuntu-jammy 2022-10-26 16:48:22 upgrade fwupd:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade libfwupdplugin5:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade libfwupd2:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade gdb:amd64 12.0.90-0ubuntu1 12.1-0ubuntu1~22.04 2022-10-26 16:48:22 upgrade grub-efi-amd64:amd64 2.06-2ubuntu7 2.06-2ubuntu10 2022-10-26 16:48:22 upgrade grub-efi-amd64-signed:amd64 1.180+2.06-2ubuntu7 1.182~22.04.1+2.06-2ubuntu10 2022-10-26 16:48:22 upgrade grub-efi-amd64-bin:amd64 2.06-2ubuntu7 2.06-2ubuntu10 2022-10-26 16:48:22 upgrade linux-firmware:all 20220329.git681281e4-0ubuntu3.5 20220329.git681281e4-0ubuntu3.6 2022-10-26 16:48:26 upgrade qemu-system-gui:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-block-extra:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-x86:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-common:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-utils:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-data:all 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:27 upgrade snapd:amd64 2.57.4+22.04 2.57.5+22.04 2022-10-26 16:48:27 upgrade teamviewer:amd64 15.34.4 15.35.5 2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade sssd:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade python3-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-proxy:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-krb5:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ad:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ldap:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ipa:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-krb5-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ad-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade libnss-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libpam-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-certmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-nss-idmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-idmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libipa-hbac0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade ovmf:all 2022.02-3 2022.02-3ubuntu0.22.04.1 I suppose this bug is here: 2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 lsb_release -rd Description: Ubuntu 22.04.1 LTS Release: 22.04 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg
[Touch-packages] [Bug 1991141] Re: "aa-disable" fails on autopkgtest.u.c (armhf)
aa-disable calls apparmor_parser, so this is most likely a problem between apparmor_parser and the kernel. I've updated the summary accordingly. ** Summary changed: - "aa-disable" fails on autopkgtest.u.c (armhf) + parser fails to unload profile via "aa-disable" on autopkgtest.u.c (armhf) - "Permission denied" -- 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/1991141 Title: parser fails to unload profile via "aa-disable" on autopkgtest.u.c (armhf) - "Permission denied" Status in apparmor package in Ubuntu: New Status in django-auth-ldap package in Ubuntu: New Status in volatildap package in Ubuntu: New Bug description: This bug affects django-auth-ldap and other packages that call "aa- disable" in a dep8 test. For some reason that I wasn't able to determine, the command fails when it's executed on autopkgtest.ubuntu.com, but only when run on armhf. The error looks like this: ERROR: /sbin/apparmor_parser: Unable to remove "/usr/sbin/slapd". Permission denied; attempted to load a profile while confined? Disabling /usr/sbin/slapd. https://autopkgtest.ubuntu.com/results/autopkgtest- kinetic/kinetic/armhf/d/django-auth-ldap/20220927_015039_0a1ae@/log.gz I wasn't able to reproduce the problem. I believe it's something specific to how autopkgtest.u.c launches the armhf containers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1991141/+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 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing
Based on your DENIED message, I wonder if read (= directory listing) permissions are really needed, or if /var/cache/samba/printing/ w, # without r would be enough. Can you please test and report back? -- 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/1993572 Title: samba profile: missing rule for mkdir /var/cache/samba/printing Status in apparmor package in Ubuntu: New Bug description: After the fix for bug #1990692, one more rule is needed it seems. I put all samba profiles in enforce mode, and when I ran that final command, got an error and an apparmor denied message: $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2' cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error NT_STATUS_CONNECTION_DISCONNECTED do_cmd: Could not initialise spoolss. Error was NT_STATUS_CONNECTION_DISCONNECTED [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342): apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd- k-samba-apparmor_" profile="samba-rpcd- spoolss" name="/var/cache/samba/printing/" pid=129107 comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100 ouid=100 And indeed, that directory wasn't created: $ l /var/cache/samba/printing ls: cannot access '/var/cache/samba/printing': No such file or directory $ l /var/cache/samba/ total 16K drwxr-xr-x 1 root root 48 Oct 19 17:42 . drwxr-xr-x 1 root root 170 Oct 19 17:41 .. -rw-r--r-- 1 root root 166 Oct 19 17:42 browse.dat -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
A few comments and explanations: > As part of that it locks down /dev to read-only: > /dev/ r, > > However that also means /dev/pts is read-only, hence the error above denies > write access. The rule for /dev/ only allows reading the directory listing of /dev/. It doesn't say or allow anything for /dev/pts/. > [ 9119.221342] audit: type=1400 audit(1666766810.741:452): apparmor="DENIED" > operation="getattr" info="Failed name lookup - disconnected path" error=-13 > [...] > name="apparmor/.null" name="apparmor/.null" is a special replacement - IIRC for files or open file handles that should not be available inside the namespace. However, I'm not completely sure about this - maybe someone else can add a better explanation. > Also is "/dev r" a faulty permission? Not really faulty, just useless ;-) This rule would allow to read the _file_ /dev, but since /dev is a directory, the rule doesn't give you any useful permissions. You probably want "/dev/ r," which allows to read the directory listing (think of "ls -l /dev"). > It's notable that after I reload the apparmor profile, and sometimes > randomly, the current terminal > session has this issue go away - it seems it can resolve the path for a > while. e.g. if i add and > then remove the consoles abstraction, it suddenly works inside that session. > But if I logout/login > it breaks again. Wild guess: are the lxd-related profiles autogenerated, and get overwritten when you logout/login or for other reasons? Besides that, you could in theory hit a cache issue (even if it sounds unlikely in this case - changing a profile should also update its timestamp). If in doubt, check audit.log or syslog when the profile gets reloaded. You should see different messages if the profile loaded into the kernel actually changed or not. -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd
[Touch-packages] [Bug 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1
** Patch added: "openssh_9.0p1-1ubuntu8.debdiff" https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993478/+attachment/5627076/+files/openssh_9.0p1-1ubuntu8.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1993478 Title: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1 Status in openssh package in Ubuntu: Triaged Status in openssh source package in Kinetic: Triaged Bug description: [Impact] Users with /etc/ssh/sshd_config's that contain ListenAddress entries with the port specified will not be migrated to socket-activated ssh correctly, or may be migrated when they should not be (e.g. if ListenAddress, with a port number, is specified more than once). This leaves users with a broken sshd configuration. [Test Plan] There are 4 tests that should be used to verify the fix: 1. Upgrade to Kinetic with just one ListenAddress entry, which specifies port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, ssh.socket will be active/listening, and /etc/systemd/system/ssh.socket.d/addresses.conf will contain the following: [Socket] ListenStream= ListenStream=0.0.0.0:1234 2. Upgrade to Kinetic with multiple ListenAddress entries, each specifying port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, migration will be attempted despite the multiple ListenAddress options, and ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, the ListenAddress option will be parsed correctly, and migration will not be attempted. 3. On a Kinetic system which was migrated, but with errors (e.g. test case #1, prior to being patched), installing the new package should correct the ssh.socket configuration. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable -proposed before the upgrade. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. * The ssh.socket configuration should be fixed, and /etc/systemd/system/ssh.socket.d/addresses.conf should contain: [Socket] ListenStream= ListenStream=0.0.0.0:1234 4. On a Kinetic system which was incorrectly migrated to ssh socket activation (e.g. test case #2, prior to being patched), installing the new package reverts to the previous behavior. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable -proposed before the upgrade. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. * The socket-activated ssh migration should be reverted, and ssh.service should be
[Touch-packages] [Bug 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
** Description changed:
[Impact]
When attempting to authenticate against a Windows Active Directory
server configured to require SASL channel binding over SSL/TLS ldap
connections (ldaps), authentication will fail stating invalid
credentials as the cause.
This is due to cyrus-sasl2 missing the sasl channel binding feature of
GSSAPI/GSS-SPNEGO.
Furthermore, for interoperability with Windows Active Directory Server,
it's necessary to be able to set the SASL SSF (security strength factor)
to 0 (zero) when it's used over an already encrypted connection like
ldaps.
To fix these issues, these items are added as patches from a set of
upstream commits.
[Test Plan]
To reproduce this issue, a machine running Windows with Active Directory
must be available over the network. As an example, for Windows Server
2019 Evaluation:
The ISO can be downloaded from
https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019
Install Windows Server, Active Directory, and Certificate Services, then add
the following registry changes from
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"ldapserverintegrity"=dword:0002
"LdapEnforceChannelBinding"=dword:0002
Also enable LDAP logging for Active Directory:
Reg Add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v
"16 LDAP Interface Events" /t REG_DWORD /d 2
With the Windows machine available, set up an Ubuntu system on a network
that can reach the Windows server. This works best and with less
configuration needed if the Windows server is acting as DNS and DHCP
server for that network.
Install packages with:
$ sudo apt install ldap-utils libsasl2-modules-gssapi-mit krb5-user
When the Configuring Kerberos Authentication prompt shows up, use the realm
of the Windows Server. If prompted, use the windows server IP for the Kerberos
KDC and admin servers.
Save the Windows Server AD CA certificate file as
/usr/local/share/ca-certificates/ad-ca.crt then run
$ sudo update-ca-certificates
In /etc/ldap/ldap.conf set
BASE dc={REALM NAME} # split the domain components like dc=example,dc=com
URI ldaps://{WINDOWS SERVER MACHINE NAME}.{REALM NAME}
With Ubuntu set up, the actual test can be run:
$ kinit
Enter Password
$ ldapwhoami -Y GSSAPI -O maxssf=0 -o SASL_CBINDING=tls-endpoint
Prior to the fix, this would display the following:
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-..., comment:
AcceptSecurityContext error, data 80090346, v4563
With the fix, the authentication will display the user information.
The same happens with
$ ldapwhoami -Y GSS-SPNEGO -O maxssf=0 -o SASL_CBINDING=tls-endpoint
SASL/GSS-SPNEGO authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-..., comment:
AcceptSecurityContext error, data 80090346, v4563
[Where problems could occur]
Based on the patches added, any problems that show up would likely
occour either in the gssapi plugin or the SASL2 macros. The two files
changed are plugins/gssapi.c and m4/sasl2.m4, along with some tests.
There are various situations apart from this one in which GSS-API can be
used, and this change may affect the way some of these interactions over
the network are handled.
In parallel with this SRU, we tested, in jammy, cyrus-imapd server and
gssapi authentication over tls, with and without this updated sasl
package. Using as a client thunderbird, imtest (from cyrus-imapd-
clients), curl (it has imap support), mutt, evolution. All authenticated
without issues. Also postfix with gssapi authentication was tested, and
also worked.
[Other Info]
This issue was fixed in kinetic in version 2.1.28+dfsg-6ubuntu2
+ This SRU is also pulling in the new DEP8 tests in the kinetic package
+ for cyrus-sasl2. The only changes made to those tests are the list of
+ mechanisms to test, which is slightly smaller in jammy, and an extra
+ package to install for one of the tests due to packaging differences in
+ jammy wrt kinetic.
+
+
[Original Description]
> Are you uncertain if your issue is really a bug?
Effect is an authentication error. Root case is a "missing feature" (see
below) and requires updating dependencies, downporting.
> If you are certain this is a bug please include the source package the bug
is in.
It's in the interaction between three libraries: openldap, cyrus-sasl, krb5
> 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System ->
About Ubuntu
Broken in 18.04 and also in 20.10 (I guess it's also broken in
[Touch-packages] [Bug 1994810] Re: rsync 3.2.3 to module broken with read-only system error
** Description changed: There is a issue rsyncing to a rsync module with the error: failed: Read-only file system (30) Both server are ubuntu 22.04.1 with rsync version 3.2.3-8ubuntu3 I tried with no success "use chroot" different value options Permissions are OK in the end side Installing manually rsync package version 3.1.3-8ubuntu0.4 from ubuntu 20 in the end side server solves the issue (without any configuration changes) Also, a workaround (both same version of rsync), is to use the following parameters in rsync: -e ssh however, this might not work for automated cron scripts. 1) Start side server command: rsync -rptoglav /tmp/test/ ::test 2) End side server configuration of rsyncd.conf: === [test] - path = /tmp/test - read only = false - uid = root - gid = root + path = /etc/letsencrypt + read only = false + uid = root + gid = root === -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1994810 Title: rsync 3.2.3 to module broken with read-only system error Status in rsync package in Ubuntu: New Bug description: There is a issue rsyncing to a rsync module with the error: failed: Read-only file system (30) Both server are ubuntu 22.04.1 with rsync version 3.2.3-8ubuntu3 I tried with no success "use chroot" different value options Permissions are OK in the end side Installing manually rsync package version 3.1.3-8ubuntu0.4 from ubuntu 20 in the end side server solves the issue (without any configuration changes) Also, a workaround (both same version of rsync), is to use the following parameters in rsync: -e ssh however, this might not work for automated cron scripts. 1) Start side server command: rsync -rptoglav /tmp/test/ ::test 2) End side server configuration of rsyncd.conf: === [test] path = /etc/letsencrypt read only = false uid = root gid = root === To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1994810/+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 1982693] Re: USB-Audio device UMC204HD disappears after suspend
I tried an unbind/bind with the xhci_hcd driver as explained here: https://stackoverflow.com/questions/35605178/ubuntu-sound-network-usb- trouble-after-suspend-how-to-restart It didn't help. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1982693 Title: USB-Audio device UMC204HD disappears after suspend Status in alsa-driver package in Ubuntu: New Bug description: Coming back from sleep, Behringer UMC204HD is not in the list of devices in Settings > Sound. It comes back if I unplug and plug back in. I tried with/without a USB hub in between, I tried setting "usbcore.autosuspend=-1". No help. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-41.44-generic 5.15.39 Uname: Linux 5.15.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jul 24 15:04:57 2022 InstallationDate: Installed on 2022-04-21 (93 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:U192k successful Symptom_Card: HD Webcam C525 - HD Webcam C525 Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: None of the above Title: [USB-Audio - UMC204HD 192k, playback] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/16/2018 dmi.bios.release: 5.12 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2.H0 dmi.board.asset.tag: Default string dmi.board.name: H110M PRO-VH (MS-7996) dmi.board.vendor: MSI dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2.H0:bd06/16/2018:br5.12:svnMSI:pnMS-7996:pvr1.0:rvnMSI:rnH110MPRO-VH(MS-7996):rvr1.0:cvnMSI:ct3:cvr1.0:skuDefaultstring: dmi.product.family: Default string dmi.product.name: MS-7996 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: MSI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1982693/+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 1994810] [NEW] rsync 3.2.3 to module broken with read-only system error
Public bug reported: There is a issue rsyncing to a rsync module with the error: failed: Read-only file system (30) Both server are ubuntu 22.04.1 with rsync version 3.2.3-8ubuntu3 I tried with no success "use chroot" different value options Permissions are OK in the end side Installing manually rsync package version 3.1.3-8ubuntu0.4 from ubuntu 20 in the end side server solves the issue (without any configuration changes) Also, a workaround (both same version of rsync), is to use the following parameters in rsync: -e ssh however, this might not work for automated cron scripts. 1) Start side server command: rsync -rptoglav /tmp/test/ ::test 2) End side server configuration of rsyncd.conf: === [test] path = /tmp/test read only = false uid = root gid = root === ** Affects: rsync (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1994810 Title: rsync 3.2.3 to module broken with read-only system error Status in rsync package in Ubuntu: New Bug description: There is a issue rsyncing to a rsync module with the error: failed: Read-only file system (30) Both server are ubuntu 22.04.1 with rsync version 3.2.3-8ubuntu3 I tried with no success "use chroot" different value options Permissions are OK in the end side Installing manually rsync package version 3.1.3-8ubuntu0.4 from ubuntu 20 in the end side server solves the issue (without any configuration changes) Also, a workaround (both same version of rsync), is to use the following parameters in rsync: -e ssh however, this might not work for automated cron scripts. 1) Start side server command: rsync -rptoglav /tmp/test/ ::test 2) End side server configuration of rsyncd.conf: === [test] path = /tmp/test read only = false uid = root gid = root === To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1994810/+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 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1
** Description changed: + [Impact] + + Users with /etc/ssh/sshd_config's that contain ListenAddress entries + with the port specified will not be migrated to socket-activated ssh + correctly, or may be migrated when they should not be (e.g. if + ListenAddress, with a port number, is specified more than once). This + leaves users with a broken sshd configuration. + + [Test Plan] + + There are 4 tests that should be used to verify the fix: + + 1. Upgrade to Kinetic with just one ListenAddress entry, which specifies + port number. + + * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: + + [...defaults everywhere else...] + + #Port 22 + #AddressFamily any + #ListenAddress 0.0.0.0 + #ListenAddress :: + ListenAddress 0.0.0.0:1234 + + [...defaults everywhere else...] + + * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. + * Before running the upgrade, make sure -proposed is enabled. + * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). + * On an affected system, ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: + + [Socket] + ListenStream= + + * On a patched system, ssh.socket will be active/listening, and + /etc/systemd/system/ssh.socket.d/addresses.conf will contain the + following: + + [Socket] + ListenStream= + ListenStream=0.0.0.0:1234 + + 2. Upgrade to Kinetic with multiple ListenAddress entries, each + specifying port number. + + * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: + + [...defaults everywhere else...] + + #Port 22 + #AddressFamily any + #ListenAddress 0.0.0.0 + #ListenAddress :: + ListenAddress 0.0.0.0:1234 + ListenAddress [::]:4321 + + [...defaults everywhere else...] + + * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. + * Before running the upgrade, make sure -proposed is enabled. + * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). + * On an affected system, migration will be attempted despite the multiple ListenAddress options, and ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: + + [Socket] + ListenStream= + + * On a patched system, the ListenAddress option will be parsed + correctly, and migration will not be attempted. + + 3. On a Kinetic system which was migrated, but with errors (e.g. test + case #1, prior to being patched), installing the new package should + correct the ssh.socket configuration. + + + * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: + + [...defaults everywhere else...] + + #Port 22 + #AddressFamily any + #ListenAddress 0.0.0.0 + #ListenAddress :: + ListenAddress 0.0.0.0:1234 + + [...defaults everywhere else...] + + * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. + * Do NOT enable -proposed before the upgrade. + * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). + * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. + + * The ssh.socket configuration should be fixed, and /etc/systemd/system/ssh.socket.d/addresses.conf should contain: + [Socket] + ListenStream= + ListenStream=0.0.0.0:1234 + + 4. On a Kinetic system which was incorrectly migrated to ssh socket + activation (e.g. test case #2, prior to being patched), installing the + new package reverts to the previous behavior. + + * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: + + [...defaults everywhere else...] + + #Port 22 + #AddressFamily any + #ListenAddress 0.0.0.0 + #ListenAddress :: + ListenAddress 0.0.0.0:1234 + ListenAddress [::]:4321 + + [...defaults everywhere else...] + + * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. + * Do NOT enable -proposed before the upgrade. + * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). + * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. + * The socket-activated ssh migration should be reverted, and ssh.service should be running as before upgrade to Kinetic. + + [Where problems could occur] + These changes are in the openssh-server.postinst script, specifically in the socket-activated ssh migration logic. Regressions would be seen in the migration logic, for example breaking a previously-working migration scenario. + + + [Original Description] + update failed... ProblemType: Package DistroRelease: Ubuntu 22.10 Package: openssh-server 1:9.0p1-1ubuntu7 ProcVersionSignature: Ubuntu
[Touch-packages] [Bug 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1
** Also affects: openssh (Ubuntu Kinetic) Importance: Critical Status: Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1993478 Title: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1 Status in openssh package in Ubuntu: Triaged Status in openssh source package in Kinetic: Triaged Bug description: [Impact] Users with /etc/ssh/sshd_config's that contain ListenAddress entries with the port specified will not be migrated to socket-activated ssh correctly, or may be migrated when they should not be (e.g. if ListenAddress, with a port number, is specified more than once). This leaves users with a broken sshd configuration. [Test Plan] There are 4 tests that should be used to verify the fix: 1. Upgrade to Kinetic with just one ListenAddress entry, which specifies port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, ssh.socket will be active/listening, and /etc/systemd/system/ssh.socket.d/addresses.conf will contain the following: [Socket] ListenStream= ListenStream=0.0.0.0:1234 2. Upgrade to Kinetic with multiple ListenAddress entries, each specifying port number. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Before running the upgrade, make sure -proposed is enabled. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * On an affected system, migration will be attempted despite the multiple ListenAddress options, and ssh.socket will fail with `bad-setting` because /etc/systemd/system/ssh.socket.d/address.conf contains: [Socket] ListenStream= * On a patched system, the ListenAddress option will be parsed correctly, and migration will not be attempted. 3. On a Kinetic system which was migrated, but with errors (e.g. test case #1, prior to being patched), installing the new package should correct the ssh.socket configuration. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable -proposed before the upgrade. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. * The ssh.socket configuration should be fixed, and /etc/systemd/system/ssh.socket.d/addresses.conf should contain: [Socket] ListenStream= ListenStream=0.0.0.0:1234 4. On a Kinetic system which was incorrectly migrated to ssh socket activation (e.g. test case #2, prior to being patched), installing the new package reverts to the previous behavior. * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the following: [...defaults everywhere else...] #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: ListenAddress 0.0.0.0:1234 ListenAddress [::]:4321 [...defaults everywhere else...] * Run `systemctl restart ssh.service` and confirm that the new configuration works as expected. * Do NOT enable -proposed before the upgrade. * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in /etc/update-manager/release-upgrades if needed). * After the openssh-server configuration fails, enable -proposed, and upgrade openssh-server. * The socket-activated ssh migration should be reverted, and ssh.service should be running as before upgrade to Kinetic. [Where problems could occur] These changes are
[Touch-packages] [Bug 1994697] [NEW] 1400x900 (3:2) resolution mismatch
Public bug reported: The listed resolution 1400x900 (3:2) it's not correct: my monitor is 16:10 and I can see black bars. I suppose the real resolution is 1400x960 (3:2), but the actual 1400x900 (16:10) is missing. I updated some packages today and the issue came after reboot: 2022-10-26 16:48:06 upgrade google-chrome-stable:amd64 106.0.5249.119-1 107.0.5304.68-1 2022-10-26 16:48:14 upgrade tzdata:all 2022c-0ubuntu0.22.04.0 2022e-0ubuntu0.22.04.0 2022-10-26 16:48:14 upgrade alsa-ucm-conf:all 1.2.6.3-1ubuntu1 1.2.6.3-1ubuntu1.1 2022-10-26 16:48:14 upgrade docker-ce-cli:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:18 upgrade docker-ce:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:20 upgrade docker-ce-rootless-extras:amd64 5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy 2022-10-26 16:48:20 upgrade docker-compose-plugin:amd64 2.12.0~ubuntu-jammy 2.12.2~ubuntu-jammy 2022-10-26 16:48:21 upgrade docker-scan-plugin:amd64 0.17.0~ubuntu-jammy 0.21.0~ubuntu-jammy 2022-10-26 16:48:22 upgrade fwupd:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade libfwupdplugin5:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade libfwupd2:amd64 1.7.5-3 1.7.9-1~22.04.1 2022-10-26 16:48:22 upgrade gdb:amd64 12.0.90-0ubuntu1 12.1-0ubuntu1~22.04 2022-10-26 16:48:22 upgrade grub-efi-amd64:amd64 2.06-2ubuntu7 2.06-2ubuntu10 2022-10-26 16:48:22 upgrade grub-efi-amd64-signed:amd64 1.180+2.06-2ubuntu7 1.182~22.04.1+2.06-2ubuntu10 2022-10-26 16:48:22 upgrade grub-efi-amd64-bin:amd64 2.06-2ubuntu7 2.06-2ubuntu10 2022-10-26 16:48:22 upgrade linux-firmware:all 20220329.git681281e4-0ubuntu3.5 20220329.git681281e4-0ubuntu3.6 2022-10-26 16:48:26 upgrade qemu-system-gui:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-block-extra:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-x86:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-common:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-utils:amd64 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:26 upgrade qemu-system-data:all 1:6.2+dfsg-2ubuntu6.4 1:6.2+dfsg-2ubuntu6.5 2022-10-26 16:48:27 upgrade snapd:amd64 2.57.4+22.04 2.57.5+22.04 2022-10-26 16:48:27 upgrade teamviewer:amd64 15.34.4 15.35.5 2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade sssd:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade python3-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-proxy:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-krb5:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ad:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ldap:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ipa:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-krb5-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-ad-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade sssd-common:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:35 upgrade libnss-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libpam-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-certmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-nss-idmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libsss-idmap0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade libipa-hbac0:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2 2022-10-26 16:48:36 upgrade ovmf:all 2022.02-3 2022.02-3ubuntu0.22.04.1 I suppose this bug is here: 2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 2:21.1.3-2ubuntu2.2 lsb_release -rd Description:Ubuntu 22.04.1 LTS Release:22.04 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-52.58-generic 5.15.60 Uname: Linux 5.15.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permesso negato: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Oct 26
[Touch-packages] [Bug 1994562] [NEW] Ubuntu settings gets very laggy most of the times in 22.10
Public bug reported: Everything related to settings in the newly released Ubuntu 22.10 is very laggy. It might work fine for a while, then when I try scrolling, it laggs and nothing happens for a few seconds. It might even crash. This happens in Settings, in Extension Manager or some GS extension's settings. ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: ubuntu-settings 22.10.1 ProcVersionSignature: Ubuntu 5.19.0-23.24-generic 5.19.7 Uname: Linux 5.19.0-23-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed Oct 26 15:47:01 2022 InstallationDate: Installed on 2022-10-24 (2 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221020) PackageArchitecture: all SourcePackage: ubuntu-settings UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ubuntu-settings (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug kinetic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/1994562 Title: Ubuntu settings gets very laggy most of the times in 22.10 Status in ubuntu-settings package in Ubuntu: New Bug description: Everything related to settings in the newly released Ubuntu 22.10 is very laggy. It might work fine for a while, then when I try scrolling, it laggs and nothing happens for a few seconds. It might even crash. This happens in Settings, in Extension Manager or some GS extension's settings. ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: ubuntu-settings 22.10.1 ProcVersionSignature: Ubuntu 5.19.0-23.24-generic 5.19.7 Uname: Linux 5.19.0-23-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed Oct 26 15:47:01 2022 InstallationDate: Installed on 2022-10-24 (2 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221020) PackageArchitecture: all SourcePackage: ubuntu-settings UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/1994562/+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 1971984] Re: pcscd 1.9.5-3 do not start automatically, only manual
Incomprehensible, a new reboot solved my issue -- 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/1971984 Title: pcscd 1.9.5-3 do not start automatically, only manual Status in pcsc-lite package in Ubuntu: Confirmed Bug description: Ubuntu Mate 22.04 with the latest updates. Problem is present with internal smart-card reader and also external usb smart-card reader. eid-viewer sees no card reader,but When i do: sudo pcscd -f it is working, also following the tips of Ludovic: https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html sudo systemctl stop pcscd.socket sudo systemctl start pcscd.socket It is working until next restart. libacsccid1 version: 1.1.8-1 libccid version: 1.5.0-2 pcscd version: 1.9.5-3 eid-archive version: 2022.3 eid-mw version: 5.0.28v5.0.28-0u2204-1 eid-viewer version: 5.0.28v5.0.28-0u2204-1 In Firefox, my eid card is then also recognized, but only in the ESR version, but this is a know Mozilla bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/1971984/+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 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
"git tag --contains 67c0460b89cc1b0644a1a59af78284dfd8d720af" shows that no release contains the upstream commit yet. ** Description changed: https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. - Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks + + Upstream commit: + + ``` + commit 67c0460b89cc1b0644a1a59af78284dfd8d720af + Author: Alon Bar-Lev + Date: Tue Jul 26 15:17:06 2022 +0300 + + Handle SMIME_crlf_copy return code + + Currently the SMIME_crlf_copy result is ignored in all usages. It does + return failure when memory allocation fails. + + This patch handles the SMIME_crlf_copy return code in all occurrences. + + Signed-off-by: Alon Bar-Lev + + Reviewed-by: Tomas Mraz + Reviewed-by: Paul Dale + Reviewed-by: Hugo Landau + (Merged from https://github.com/openssl/openssl/pull/18876) + ``` ** Changed in: openssl (Ubuntu) Status: New => Triaged ** Changed in: openssl (Ubuntu) Importance: Undecided => Medium ** Also affects: openssl (Ubuntu Kinetic) Importance: Medium Status: Triaged ** Also affects: openssl (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu Jammy) Status: New => Triaged ** Changed in: openssl (Ubuntu Jammy) Importance: Undecided => High ** Changed in: openssl (Ubuntu Jammy) Importance: High => Medium -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Triaged Status in openssl source package in Jammy: Triaged Status in openssl source package in Kinetic: Triaged Bug description: https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 1971984] Re: pcscd 1.9.5-3 do not start automatically, only manual
Hello, I am facing a very similar issue I managed to make it work on fresh install but it stopped working after a reboot The two commands above do not resolve on my laptop $ sudo service pcscd status ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) since Wed 2022-10-26 13:52:17 CEST; 6min ago TriggeredBy: ● pcscd.socket Docs: man:pcscd(8) Main PID: 88997 (code=exited, status=0/SUCCESS) CPU: 13ms oct 26 13:50:59 dadbert systemd[1]: Started PC/SC Smart Card Daemon. oct 26 13:51:06 dadbert pcscd[88997]: ccid_usb.c:886:WriteUSB() write failed (3/3): LIBUSB_ERROR_TIMEOUT oct 26 13:51:11 dadbert pcscd[88997]: 05000646 ccid_usb.c:886:WriteUSB() write failed (3/3): LIBUSB_ERROR_TIMEOUT oct 26 13:51:16 dadbert pcscd[88997]: 05000454 ccid_usb.c:886:WriteUSB() write failed (3/3): LIBUSB_ERROR_TIMEOUT oct 26 13:51:16 dadbert pcscd[88997]: 0036 ifdhandler.c:202:CreateChannelByNameOrChannel() failed oct 26 13:51:16 dadbert pcscd[88997]: 0277 readerfactory.c:1138:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5842:libudev:1:/dev/bus/usb/003/003) oct 26 13:51:16 dadbert pcscd[88997]: 0017 readerfactory.c:380:RFAddReader() Broadcom Corp 58200 [Contacted SmartCard] (0123456789ABCD) init failed. oct 26 13:51:16 dadbert pcscd[88997]: 0112 hotplug_libudev.c:538:HPAddDevice() Failed adding USB device: Broadcom Corp 58200 oct 26 13:52:17 dadbert systemd[1]: pcscd.service: Deactivated successfully. $ lsusb Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0a5c:5842 Broadcom Corp. 58200 ... $ pcscd --version pcsc-lite version 1.9.5. Copyright (C) 1999-2002 by David Corcoran . Copyright (C) 2001-2018 by Ludovic Rousseau . Copyright (C) 2003-2004 by Damien Sauveron . ... OS: Ubuntu 22.04 Dell Precision 7670 -- 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/1971984 Title: pcscd 1.9.5-3 do not start automatically, only manual Status in pcsc-lite package in Ubuntu: Confirmed Bug description: Ubuntu Mate 22.04 with the latest updates. Problem is present with internal smart-card reader and also external usb smart-card reader. eid-viewer sees no card reader,but When i do: sudo pcscd -f it is working, also following the tips of Ludovic: https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html sudo systemctl stop pcscd.socket sudo systemctl start pcscd.socket It is working until next restart. libacsccid1 version: 1.1.8-1 libccid version: 1.5.0-2 pcscd version: 1.9.5-3 eid-archive version: 2022.3 eid-mw version: 5.0.28v5.0.28-0u2204-1 eid-viewer version: 5.0.28v5.0.28-0u2204-1 In Firefox, my eid card is then also recognized, but only in the ESR version, but this is a know Mozilla bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/1971984/+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 1988196] Re: presage: ftbfs with GCC-11
** Changed in: presage (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to presage in Ubuntu. https://bugs.launchpad.net/bugs/1988196 Title: presage: ftbfs with GCC-11 Status in presage package in Ubuntu: Fix Released Status in presage package in Debian: Fix Released Bug description: Imported from Debian bug http://bugs.debian.org/984297: Package: src:presage Version: 0.9.1-2.2 Severity: normal Tags: sid bookworm User: debian-...@lists.debian.org Usertags: ftbfs-gcc-11 [This bug is not targeted to the upcoming bullseye release] Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The severity of this report will be raised before the bookworm release, so nothing has to be done for the bullseye release. The full build log can be found at: http://people.debian.org/~doko/logs/20210228/filtered/gcc11/presage_0.9.1-2.2_unstable_gcc11.log The last lines of the build log are at the end of this report. To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-11/porting_to.html GCC 11 defaults to the GNU++17 standard. If your package installs header files in /usr/include, please don't work around C++17 issues by choosing a lower C++ standard for the package build, but fix these issues to build with the C++17 standard. [...] presage.h:199:33: error: ISO C++17 does not allow dynamic exception specifications 199 | std::string context() const throw (PresageException); | ^ presage.h:206:33: error: ISO C++17 does not allow dynamic exception specifications 206 | bool context_change() const throw (PresageException); | ^ presage.h:212:32: error: ISO C++17 does not allow dynamic exception specifications 212 | std::string prefix() const throw (PresageException); |^ presage.h:221:58: error: ISO C++17 does not allow dynamic exception specifications 221 | std::string config(const std::string variable) const throw (PresageException); | ^ presage.h:230:76: error: ISO C++17 does not allow dynamic exception specifications 230 | void config(const std::string variable, const std::string value) const throw (PresageException); | ^ presage.h:239:30: error: ISO C++17 does not allow dynamic exception specifications 239 | void save_config() const throw (PresageException); | ^ presage.cpp:34:5: error: ISO C++17 does not allow dynamic exception specifications 34 | throw (PresageException) | ^ presage.cpp:45:5: error: ISO C++17 does not allow dynamic exception specifications 45 | throw (PresageException) | ^ presage.cpp:65:5: error: ISO C++17 does not allow dynamic exception specifications 65 | throw (PresageException) | ^ presage.cpp:91:5: error: ISO C++17 does not allow dynamic exception specifications 91 | throw (PresageException) | ^ presage.cpp:140:5: error: ISO C++17 does not allow dynamic exception specifications 140 | throw (PresageException) | ^ presage.cpp:147:5: error: ISO C++17 does not allow dynamic exception specifications 147 | throw (PresageException) | ^ presage.cpp:153:5: error: ISO C++17 does not allow dynamic exception specifications 153 | throw (PresageException) | ^ presage.cpp:201:5: error: ISO C++17 does not allow dynamic exception specifications 201 | throw (PresageException) | ^ presage.cpp:207:5: error: ISO C++17 does not allow dynamic exception specifications 207 | throw (PresageException) | ^ presage.cpp:213:5: error: ISO C++17 does not allow dynamic exception specifications 213 | throw (PresageException) | ^ presage.cpp:219:5: error: ISO C++17 does not allow dynamic
[Touch-packages] [Bug 1969671] Re: Misspelled Ukrainian cities in tzdata
This bug was fixed in the package tzdata - 2022e-0ubuntu0.20.04.0 --- tzdata (2022e-0ubuntu0.20.04.0) focal; urgency=medium * New upstream releases (LP: #1992692): - Palestine transitions are now Saturdays at 02:00. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. - Simplify three Ukraine zones into one. (LP: #1969671) - Jordan and Syria switch from +02/+03 with DST to year-round * debian/tzdata.templates and debian/tzdata.config: - Convert Europe/Kiev into Europe/Kyiv - Remove Uzhgorod and Zaporozhye * Update the ICU timezone data to 2022e -- Benjamin Drung Mon, 17 Oct 2022 15:48:16 +0200 -- 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/1969671 Title: Misspelled Ukrainian cities in tzdata Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Bionic: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Bug description: When user is prompted to choose a city in the region 'Europe' they have a choice of 4 cities in Ukraine: 23. Kiev -> should be Kyiv 46. Simferopol - > OK 54. Uzhgorod -> should be Uzhhorod 62. Zaporozhye -> should be Zaporizhzhia The 'should be' variant is the only correct transliteration from Ukrainian into English. Possible useful pieces of ubuntu-bug report (run in a headless ubuntu/latest docker image): DistroRelease: Ubuntu 20.04 Package: tzdata 2022a-0ubuntu0.20.04 Tags: focal PackageArchitecture: all To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1969671/+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 1969671] Re: Misspelled Ukrainian cities in tzdata
This bug was fixed in the package tzdata - 2022e-0ubuntu0.18.04.0 --- tzdata (2022e-0ubuntu0.18.04.0) bionic; urgency=medium * New upstream releases (LP: #1992692): - Palestine transitions are now Saturdays at 02:00. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. - Simplify three Ukraine zones into one. (LP: #1969671) - Jordan and Syria switch from +02/+03 with DST to year-round * debian/tzdata.templates and debian/tzdata.config: - Convert Europe/Kiev into Europe/Kyiv - Remove Uzhgorod and Zaporozhye -- Benjamin Drung Mon, 17 Oct 2022 15:59:56 +0200 ** Changed in: tzdata (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: tzdata (Ubuntu Focal) Status: Fix Committed => Fix Released -- 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/1969671 Title: Misspelled Ukrainian cities in tzdata Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Bionic: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Bug description: When user is prompted to choose a city in the region 'Europe' they have a choice of 4 cities in Ukraine: 23. Kiev -> should be Kyiv 46. Simferopol - > OK 54. Uzhgorod -> should be Uzhhorod 62. Zaporozhye -> should be Zaporizhzhia The 'should be' variant is the only correct transliteration from Ukrainian into English. Possible useful pieces of ubuntu-bug report (run in a headless ubuntu/latest docker image): DistroRelease: Ubuntu 20.04 Package: tzdata 2022a-0ubuntu0.20.04 Tags: focal PackageArchitecture: all To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1969671/+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 1969671] Update Released
The verification of the Stable Release Update for tzdata has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1969671 Title: Misspelled Ukrainian cities in tzdata Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Bionic: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Bug description: When user is prompted to choose a city in the region 'Europe' they have a choice of 4 cities in Ukraine: 23. Kiev -> should be Kyiv 46. Simferopol - > OK 54. Uzhgorod -> should be Uzhhorod 62. Zaporozhye -> should be Zaporizhzhia The 'should be' variant is the only correct transliteration from Ukrainian into English. Possible useful pieces of ubuntu-bug report (run in a headless ubuntu/latest docker image): DistroRelease: Ubuntu 20.04 Package: tzdata 2022a-0ubuntu0.20.04 Tags: focal PackageArchitecture: all To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1969671/+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 1969671] Re: Misspelled Ukrainian cities in tzdata
This bug was fixed in the package tzdata - 2022e-0ubuntu0.22.04.0 --- tzdata (2022e-0ubuntu0.22.04.0) jammy; urgency=medium * New upstream releases (LP: #1992692): - Palestine transitions are now Saturdays at 02:00. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. - Simplify three Ukraine zones into one. (LP: #1969671) - Jordan and Syria switch from +02/+03 with DST to year-round * debian/tzdata.templates and debian/tzdata.config: - Convert Europe/Kiev into Europe/Kyiv - Remove Uzhgorod and Zaporozhye * Update the ICU timezone data to 2022e -- Benjamin Drung Mon, 17 Oct 2022 15:51:00 +0200 ** Changed in: tzdata (Ubuntu Jammy) Status: Fix Committed => Fix Released -- 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/1969671 Title: Misspelled Ukrainian cities in tzdata Status in tzdata package in Ubuntu: Fix Released Status in tzdata source package in Bionic: Fix Released Status in tzdata source package in Focal: Fix Released Status in tzdata source package in Jammy: Fix Released Bug description: When user is prompted to choose a city in the region 'Europe' they have a choice of 4 cities in Ukraine: 23. Kiev -> should be Kyiv 46. Simferopol - > OK 54. Uzhgorod -> should be Uzhhorod 62. Zaporozhye -> should be Zaporizhzhia The 'should be' variant is the only correct transliteration from Ukrainian into English. Possible useful pieces of ubuntu-bug report (run in a headless ubuntu/latest docker image): DistroRelease: Ubuntu 20.04 Package: tzdata 2022a-0ubuntu0.20.04 Tags: focal PackageArchitecture: all To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1969671/+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 1992692] Re: tzdata 2022e release
This bug was fixed in the package tzdata - 2022e-0ubuntu0.20.04.0
---
tzdata (2022e-0ubuntu0.20.04.0) focal; urgency=medium
* New upstream releases (LP: #1992692):
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one. (LP: #1969671)
- Jordan and Syria switch from +02/+03 with DST to year-round
* debian/tzdata.templates and debian/tzdata.config:
- Convert Europe/Kiev into Europe/Kyiv
- Remove Uzhgorod and Zaporozhye
* Update the ICU timezone data to 2022e
-- Benjamin Drung Mon, 17 Oct 2022 15:48:16 +0200
--
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/1992692
Title:
tzdata 2022e release
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Trusty:
Fix Released
Status in tzdata source package in Xenial:
Fix Released
Status in tzdata source package in Bionic:
Fix Released
Status in tzdata source package in Focal:
Fix Released
Status in tzdata source package in Jammy:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one.
- Jordan and Syria switch from +02/+03 with DST to year-round +03.
icu update to 2022e: https://unicode-
org.atlassian.net/browse/ICU-22178
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 | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
always_before = datetime(2022, 10, 1)
now_before = datetime(2022, 10, 29)
always_after = datetime(2022, 11, 1)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022c.
[Test Case for releases <= 20.04 LTS]
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:
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/1992692/+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 1992692] Re: tzdata 2022e release
This bug was fixed in the package tzdata - 2022e-0ubuntu0.18.04.0
---
tzdata (2022e-0ubuntu0.18.04.0) bionic; urgency=medium
* New upstream releases (LP: #1992692):
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one. (LP: #1969671)
- Jordan and Syria switch from +02/+03 with DST to year-round
* debian/tzdata.templates and debian/tzdata.config:
- Convert Europe/Kiev into Europe/Kyiv
- Remove Uzhgorod and Zaporozhye
-- Benjamin Drung Mon, 17 Oct 2022 15:59:56 +0200
** Changed in: tzdata (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** Changed in: tzdata (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
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/1992692
Title:
tzdata 2022e release
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Trusty:
Fix Released
Status in tzdata source package in Xenial:
Fix Released
Status in tzdata source package in Bionic:
Fix Released
Status in tzdata source package in Focal:
Fix Released
Status in tzdata source package in Jammy:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one.
- Jordan and Syria switch from +02/+03 with DST to year-round +03.
icu update to 2022e: https://unicode-
org.atlassian.net/browse/ICU-22178
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 | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
always_before = datetime(2022, 10, 1)
now_before = datetime(2022, 10, 29)
always_after = datetime(2022, 11, 1)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022c.
[Test Case for releases <= 20.04 LTS]
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:
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/1992692/+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 1992692] Update Released
The verification of the Stable Release Update for tzdata has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.
--
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/1992692
Title:
tzdata 2022e release
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Trusty:
Fix Released
Status in tzdata source package in Xenial:
Fix Released
Status in tzdata source package in Bionic:
Fix Released
Status in tzdata source package in Focal:
Fix Released
Status in tzdata source package in Jammy:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one.
- Jordan and Syria switch from +02/+03 with DST to year-round +03.
icu update to 2022e: https://unicode-
org.atlassian.net/browse/ICU-22178
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 | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
always_before = datetime(2022, 10, 1)
now_before = datetime(2022, 10, 29)
always_after = datetime(2022, 11, 1)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022c.
[Test Case for releases <= 20.04 LTS]
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:
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/1992692/+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 1992692] Re: tzdata 2022e release
This bug was fixed in the package tzdata - 2022e-0ubuntu0.22.04.0
---
tzdata (2022e-0ubuntu0.22.04.0) jammy; urgency=medium
* New upstream releases (LP: #1992692):
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one. (LP: #1969671)
- Jordan and Syria switch from +02/+03 with DST to year-round
* debian/tzdata.templates and debian/tzdata.config:
- Convert Europe/Kiev into Europe/Kyiv
- Remove Uzhgorod and Zaporozhye
* Update the ICU timezone data to 2022e
-- Benjamin Drung Mon, 17 Oct 2022 15:51:00 +0200
** Changed in: tzdata (Ubuntu Jammy)
Status: Fix Committed => Fix Released
--
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/1992692
Title:
tzdata 2022e release
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Trusty:
Fix Released
Status in tzdata source package in Xenial:
Fix Released
Status in tzdata source package in Bionic:
Fix Released
Status in tzdata source package in Focal:
Fix Released
Status in tzdata source package in Jammy:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Palestine transitions are now Saturdays at 02:00. This means 2022 falls
back 10-29 at 02:00, not 10-28 at 01:00.
- Simplify three Ukraine zones into one.
- Jordan and Syria switch from +02/+03 with DST to year-round +03.
icu update to 2022e: https://unicode-
org.atlassian.net/browse/ICU-22178
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 | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
always_before = datetime(2022, 10, 1)
now_before = datetime(2022, 10, 29)
always_after = datetime(2022, 11, 1)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022c.
[Test Case for releases <= 20.04 LTS]
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:
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/1992692/+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 1991139] Re: prompted to remove systemd-hwe-hwdb but re-installed via updates
I think it's a bug where update-manager installs those additional packages which stems from its implementation of phased updates, but it's also not a priority to work on because this only happens when an SRU introduces a new dependency which does not happen all that often. ** Package changed: apt (Ubuntu) => update-manager (Ubuntu) ** Changed in: update-manager (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1991139 Title: prompted to remove systemd-hwe-hwdb but re-installed via updates Status in update-manager package in Ubuntu: Triaged Bug description: sudo apt upgrade gives me this : The following package was automatically installed and is no longer required: systemd-hwe-hwdb Use 'sudo apt autoremove' to remove it. The following packages have been kept back: libnss-systemd libpam-systemd libspeechd2 libsystemd0 libudev1 python3-speechd speech-dispatcher speech-dispatcher-audio-plugins speech-dispatcher-espeak-ng systemd systemd-oomd systemd-sysv systemd-timesyncd udev 0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded. sudo apt autoremove removes the no longer required systemd-hwe-hwdb but the software updater brings it back & this cycle goes on in loop. kindly check. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1991139/+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 1971712] Re: Add support for Intel DG2
** Changed in: linux-oem-6.0 (Ubuntu Jammy) Status: Fix Committed => 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/1971712 Title: Add support for Intel DG2 Status in linux-firmware package in Ubuntu: Fix Released Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux-oem-6.0 package in Ubuntu: Invalid Status in mesa package in Ubuntu: Fix Released Status in linux-firmware source package in Jammy: In Progress Status in linux-oem-5.17 source package in Jammy: Won't Fix Status in linux-oem-6.0 source package in Jammy: Confirmed Status in mesa source package in Jammy: Fix Released Bug description: [Impact] Ubuntu 22.04 does not support Intel DG2-based hw which is released later this year. [Fix] Mesa: needs a bunch of patches backported to 22.0.x, will be upstream in 22.1 or 22.2 kernel: oem-6.0 plus a bunch of backports from 6.1/drm-tip firmare: updates to i915 DMC, GuC [Test case] Boot a system with a DG2-based GPU, check that native graphics drivers are used. Test mesa also on gen9-gen12 GPU's to verify that there are no regressions even though the backports are for DG2. [What could go wrong] The Mesa patches are only for DG2 support, should not affect other hardware at all. The kernel driver is in a separate package which isn't installed by default except preinstall machines with this hardware. So other users are not affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1971712/+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 1992667] Re: Application windows invisible (on DG2 graphics)
** Changed in: linux-oem-6.0 (Ubuntu Jammy) Status: New => Invalid ** Changed in: linux-oem-6.0 (Ubuntu) Status: Incomplete => Invalid -- 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/1992667 Title: Application windows invisible (on DG2 graphics) Status in linux-oem-6.0 package in Ubuntu: Invalid Status in mesa package in Ubuntu: Fix Released Status in linux-oem-6.0 source package in Jammy: Invalid Status in mesa source package in Jammy: New Bug description: When using GNOME Shell with Wayland, all application windows become invisible from time to time. This usually happens right after starting GNOME Shell for the first time or after having a VRAM intensive application open, such as a game. I have installed the latest linux-oem-6.0 kernel and manually enabled support for DG2 graphics by passing the i915.force_probe parameter with the PCIe ID of the graphics card. I have attached a screenshot of the described behavior below. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-shell 42.4-0ubuntu0.22.04.1 ProcVersionSignature: Ubuntu 6.0.0-1005.5-oem 6.0.0 Uname: Linux 6.0.0-1005-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Wed Oct 12 17:23:40 2022 DisplayManager: gdm3 InstallationDate: Installed on 2022-10-11 (1 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 42.2-0ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.0/+bug/1992667/+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 1993869] Re: openssh-server cannot listen or bind to anything other than :::2 after upgrading to 22.10 from 22.04
** Tags removed: foundations-triage-discuss -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1993869 Title: openssh-server cannot listen or bind to anything other than :::2 after upgrading to 22.10 from 22.04 Status in openssh package in Ubuntu: Incomplete Bug description: This is a bug report to separate the second issue that was reported in this bug report: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993478 There's an issue after upgrading to 22.10 from 22.04 that prevents opensshd from listening to anything other than :::2. I already commented in the bug report I linked, so I'll just copy/paste and add some details. I guess. The issue is that after upgrading, sshd doesn't use the Listen port or ListenAddress config from the sshd_config file or any custom config file that was in the sshd_config.d drop in folder anymore. Other drop in settings from sshd.config.d seem to be applied normally, the issue seem to be only for IP binding and custom ports. If I change Accept=no by Accept=yes in ssh.socket and reloads the socket unit, I can start sshd on a different port and I can also bind the IP to something else than :: There's an issue still, an instance of sshd is still listening to :::22 that is not started by SSHD but by init. root@ubuntulocal:~# netstat -antp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 568/vsftpd tcp 0 0 0.0.0.0:622 0.0.0.0:* LISTEN 571/sshd: /usr/sbin tcp 0 272 192.168.1.225:622 192.168.1.220:2473 ESTABLISHED 1027/sshd: root@pts tcp6 0 0 :::22 :::* LISTEN 1/init If I reboot after changing this no to yes in ssh.socket does not survive a reboot and fails to load sshd with a "Failed to queue service startup job" error. Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed with result 'resources'. I had to mask/stop the sshd.socket unit and create a custom sshd service in /etc/systemd/system to be able start sshd on a custom port and IP. chris@ubuntulocal:~$ systemctl status ssh.socket ● ssh.socket - OpenBSD Secure Shell server socket Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled) Active: active (running) since Fri 2022-10-21 23:08:09 UTC; 1min 24s ago Until: Fri 2022-10-21 23:08:09 UTC; 1min 24s ago Triggers: ● ssh.service Listen: [::]:22 (Stream) Tasks: 0 (limit: 18899) Memory: 4.0K CPU: 418us CGroup: /system.slice/ssh.socket To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993869/+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 46299] Re: Can't connect to iLO on HP servers without doing "unset LANG"
Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343896#131 and mark this bug as Won't Fix. ** Changed in: openssh (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/46299 Title: Can't connect to iLO on HP servers without doing "unset LANG" Status in openssh package in Ubuntu: Won't Fix Status in openssh package in Debian: Fix Released Bug description: Binary package hint: openssh-client When trying to connect via SSH to iLO (lights out management) on Hewlett Packard Proliant servers, the SSH in Ubuntu Dapper gives the following error after authentication: dispatch_protocol_error: type 100 seq 7 buffer_get_ret: trying to get more bytes 4 than in buffer 0 buffer_get_int: buffer error Doing "unset LANG" allows the login to work fine. The full "ssh -v" output is: $ ssh -v servername -l root OpenSSH_4.2p1 Debian-7ubuntu3, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to servername [168.192.63.44] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version mpSSH_0.0.1 debug1: no match: mpSSH_0.0.1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'servername' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:245 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: password,publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/identity debug1: Trying private key: /home/user/.ssh/id_rsa debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Next authentication method: password root@servername's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_GB.UTF-8 dispatch_protocol_error: type 100 seq 7 buffer_get_ret: trying to get more bytes 4 than in buffer 0 buffer_get_int: buffer error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/46299/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
The above analysis is true for SSH, but, I realise it's different for the PTY passed in by lxc exec. So my analysis is true maybe, but I am going to move this SSH fix over to Bug #1667016 so this bug can stay open for the general PTY/buffering issue. There is a gap in my explanation of: It's not clear to me why this doesn't also happen outside of a container. Of note I found that the error I get initially suggests it couldn't resolve the path of the FD, which seems probably to be /dev/pts: [ 9119.221342] audit: type=1400 audit(1666766810.741:452): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-juju-5062b7-2-lxd-3_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=257511 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=1000108 ouid=0 However the same fix makes this go away. Is apparmor or this error message failing to identify the path for some reason because it has no permission to stat it in that apparmor context or something? Also is "/dev r" a faulty permission? It's notable that after I reload the apparmor profile, and sometimes randomly, the current terminal session has this issue go away - it seems it can resolve the path for a while. e.g. if i add and then remove the consoles abstraction, it suddenly works inside that session. But if I logout/login it breaks again. I'm a bit lost here :) -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
** Changed in: apparmor (Ubuntu) Status: Invalid => Confirmed -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1990526] Re: [FFe] UDI snap no longer strictly needed for WSL OOBE
commit 470c50d7c14f33623636f157d27c434fe5d2dedf Author: Carlos Nihelton Date: Wed Sep 21 16:09:47 2022 -0300 wsl: Replace ubuntu-desktop-installer by Subiquity snap LP: #1990526 Also removes the gtk-themes snap required by UDI. That will result in a smaller rootfs. ** Changed in: ubuntu-meta (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1990526 Title: [FFe] UDI snap no longer strictly needed for WSL OOBE Status in ubuntu-meta package in Ubuntu: Fix Released Bug description: Ubuntu Desktop Installer (UDI, for short) package implementing the WSL OOBE has been ported to Windows and the WSL application is able to launch the OOBE running as a native Win32 application, instead of relying on WSLg to display the OOBE. That implies in the possibility of replacing UDI by Subiquity snap, which results in a smaller rootfs image (besides an enhanced experience due native rendering on graphics - instead of depending on RDP as it is currently with the OOBE running inside Ubuntu). Fixing this would require: - replace UDI by Subiquity snaps in the WSL seed; - updating the wsl-setup package to the latest upstream (which is able to mount and launch Subiquity from its snap) LP: #1990426 . Following the approach above won't have effects outside of WSL. Kinetic being not an LTS is a good release to receive the fix for this first, as it affects a small audience of Ubuntu WSL community, giving us time to learn from them before backporting this to Jammy early next cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1990526/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
** Changed in: tcpdump (Ubuntu) Importance: Undecided => High -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Invalid Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1547826] Re: Enable libappindicator support
** Changed in: ibus (Ubuntu Xenial) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1547826 Title: Enable libappindicator support Status in ibus package in Ubuntu: Fix Released Status in ibus source package in Xenial: Won't Fix Status in ibus source package in Yakkety: Fix Released Bug description: It appears an FFe is needed at this stage in Xenial cycle, thus changing the bug status. ---Original Report Please enable libappindicator support. This feature is good at KDE 5. https://desktopi18n.wordpress.com/2015/07/21/ibus-1-5-11-is-released/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1547826/+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 1641236] Re: Confined processes inside container cannot fully access host pty device passed in by lxc exec
Note: This affects SSH as well.. not only lxc exec. There is a currently marked duplicate bug about the SSH part in Bug #1667016 This still persits on focal now. To workaround this for me I have to *both* use tcpdump with -l (line buffered mode) *and* pipe the output to cat. You also want to redirect stderr otherwise it's silently lost. # tcpdump -lni o-hm0 2>&1|cat The apparmor errors I get are: [ 6414.508990] audit: type=1400 audit(1666764106.013:360): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-juju-5062b7-2-lxd-3_" profile="/usr/sbin/tcpdump" name="/dev/pts/2" pid=187936 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100 ouid=1001000 I have determined the cause, which is that tcpdump is one of the few programs with its own restrictive apparmor profile (/etc/apparmor.d/usr.sbin.tcpdump). As part of that it locks down /dev to read-only: > /dev/ r, However that also means /dev/pts is read-only, hence the error above denies write access. There is an abstraction #include which adds access to /dev/pts and other console outputs. It's included also in the profile for usr.bin.man. Including this abstraction resolves the issue for me. I'll upload a patch. ** Also affects: tcpdump (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu) Status: Confirmed => Invalid ** Changed in: tcpdump (Ubuntu) Status: New => Confirmed -- 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/1641236 Title: Confined processes inside container cannot fully access host pty device passed in by lxc exec Status in apparmor package in Ubuntu: Invalid Status in lxd package in Ubuntu: Invalid Status in tcpdump package in Ubuntu: Confirmed Bug description: Now that AppArmor policy namespaces and profile stacking is in place, I noticed odd stdout buffering behavior when running confined processes via lxc exec. Much more data stdout data is buffered before getting flushed when the program is confined by an AppArmor profile inside of the container. I see that lxd is calling openpty(3) in the host environment, using the returned fd as stdout, and then executing the command inside of the container. This results in an AppArmor denial because the file descriptor returned by openpty(3) originates outside of the namespace used by the container. The denial is likely from glibc calling fstat(), from inside the container, on the file descriptor associated with stdout to make a decision on how much buffering to use. The fstat() is denied by AppArmor and glibc ends up handling the buffering differently than it would if the fstat() would have been successful. Steps to reproduce (using an up-to-date 16.04 amd64 VM): Create a 16.04 container $ lxc launch ubuntu-daily:16.04 x Run tcpdump in one terminal and generate traffic in another terminal (wget google.com) $ lxc exec x -- tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 47 packets captured 48 packets received by filter 1 packet dropped by kernel Note that everything above was printed immediately because it was printed to stderr. , which is printed to stdout, was not printed until you pressed ctrl-c and the buffers were flushed thanks to the program terminating. Also, this AppArmor denial shows up in the logs: audit: type=1400 audit(1478902710.025:440): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-x_" profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Now run tcpdump unconfined and take note that is printed immediately, before you terminate tcpdump. Also, there are no AppArmor denials. $ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0 ... Now run tcpdump confined but in lxc exec's non-interactive mode and note that is printed immediately and no AppArmor denials are present. (Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in interactive mode) $ lxc exec x --mode=non-interactive -- tcpdump -i eth0 ... Applications that manually call fflush(stdout) are not affected by this as manually flushing stdout works fine. The problem seems to be caused by glibc not being able to fstat() the /dev/pts/12 fd from the host's namespace. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+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 1986984] Re: [FFe] tzdata 2022c update
** Changed in: tzdata (Ubuntu Xenial)
Status: Confirmed => Fix Released
--
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/1986984
Title:
[FFe] tzdata 2022c update
Status in tzdata package in Ubuntu:
Fix Released
Status in tzdata source package in Xenial:
Fix Released
Status in tzdata source package in Bionic:
Fix Released
Status in tzdata source package in Focal:
Fix Released
Status in tzdata source package in Jammy:
Fix Released
Status in tzdata source package in Kinetic:
Fix Released
Bug description:
New timezone data, with the following timezones impacted:
- Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
- Iran no longer observes DST (Asia/Tehran)
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 America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499
[Test Case for releases >= 20.04 LTS]
For releases with ICU timezone data verification is done using the following
with dates before and after the change:
1) sudo apt-get install python3-icu
2) Run the following python script:
from datetime import datetime
from icu import ICUtzinfo, TimeZone
tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
always_before = datetime(2022, 9, 1)
now_before = datetime(2022, 9, 8)
always_after = datetime(2022, 9, 12)
assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
The assertions would crash on 2022a.
[Test Case for releases <= 20.04 LTS]
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:
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 |
cut -d' ' -f2-)
Nothing should be returned by the above command.
[Original report]
tzdata 2022b and 2022c were just released that includes some timezone changes
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a
change to the start of their daylight savings and pushed it from Sept 4th to
the 11th, so we really need our servers updated before the 4th.
Thanks
Jason
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1986984/+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
