[Touch-packages] [Bug 1978871] Re: apt package missing apt-auto-removal
Well you figured out the versions we stopped shipping it, so you could have just read the changelog to find out why that happened. But anyway, we no longer protect the last installed kernel. ** Changed in: apt (Ubuntu) Status: New => Invalid -- 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/1978871 Title: apt package missing apt-auto-removal Status in apt package in Ubuntu: Invalid Bug description: #> lsb_release -rd Description: Ubuntu 20.04.4 LTS Release: 20.04 #> apt-cache policy apt apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages The /etc/kernel/postinst.d/apt-auto-removal file is supposed to be included in the apt package... #> apt-file find apt-auto-removal apt: /etc/kernel/postinst.d/apt-auto-removal open-infrastructure-system-build: /usr/share/live/build/hooks/normal/0196-remote-apt-auto-removal.hook.chroot But versions 2.0.8 and 2.0.9 do not include it... #> dpkg -L apt | fgrep -i post /etc/kernel/postinst.d #> ls /etc/kernel/postinst.d/ ./ ../ initramfs-tools* xx-update-initrd-links* zz-update-grub* Can you please rebuild this package to include the missing file? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1978871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947588] Autopkgtest regression report (openssl/1.1.1f-1ubuntu2.14)
All autopkgtests for the newly accepted openssl (1.1.1f-1ubuntu2.14) for focal have finished running. The following regressions have been reported in tests triggered by the package: trafficserver/8.0.5+ds-3 (ppc64el) linux-oem-5.14/5.14.0-1042.47 (amd64) linux-hwe-5.11/5.11.0-61.61 (armhf) linux-intel-iotg-5.15/5.15.0-1008.11~20.04.1 (amd64) linux-hwe-5.15/5.15.0-33.34~20.04.1 (armhf) mysql-8.0/8.0.29-0ubuntu0.20.04.3 (amd64) puma/3.12.4-1ubuntu2 (arm64) linux-hwe-5.13/5.13.0-48.54~20.04.1 (armhf) diaspora-installer/0.7.6.1+debian1 (s390x, arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#openssl [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: Fix Committed Status in openssl source package in Impish: Fix Committed Status in openssl source package in Jammy: Fix Committed Bug description: [Impact] The TLS test server `openssl s_server` can very easily be led into an infinite loop if configured with incompatible settings and used via DTLS. This makes it harder to test one's TLS configuration. [Test plan] In one session: $ openssl s_server -nocert -psk 01020304 -dtls1 In parallel: $ openssl s_client -dtls1 -psk 01020304 The server session will enter an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ... etc... [Where problems could occur] The patch is fairly self-contained, so regressions should only occur in the `openssl s_server` application, and not in the libssl or libcrypto libraries. However, the patch could break said server, which might be used in e.g. autopkgtests. [Original report] Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-package
[Touch-packages] [Bug 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
Now I think we should file upstream bug reports with x2go (which I don't use) and nomachine and get some clarity on whether they are doing the login in compliance with up-to-date https://www.freedesktop.org/software/systemd/man/systemd- logind.service.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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 1978093] Autopkgtest regression report (openssl/1.1.1f-1ubuntu2.14)
All autopkgtests for the newly accepted openssl (1.1.1f-1ubuntu2.14) for focal have finished running. The following regressions have been reported in tests triggered by the package: trafficserver/8.0.5+ds-3 (ppc64el) linux-oem-5.14/5.14.0-1042.47 (amd64) linux-hwe-5.11/5.11.0-61.61 (armhf) linux-intel-iotg-5.15/5.15.0-1008.11~20.04.1 (amd64) linux-hwe-5.15/5.15.0-33.34~20.04.1 (armhf) mysql-8.0/8.0.29-0ubuntu0.20.04.3 (amd64) puma/3.12.4-1ubuntu2 (arm64) linux-hwe-5.13/5.13.0-48.54~20.04.1 (armhf) diaspora-installer/0.7.6.1+debian1 (s390x, arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#openssl [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1978093 Title: openssl: FTBFS due to expired certificates Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Status in openssl source package in Focal: Fix Committed Status in openssl source package in Impish: Fix Committed Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Fix Released Bug description: [Impact] Some certificates in the openssl package expired on 2022-06-01, making the test suite fail. This needs to be fixed to facilitate future security updates. [Test Plan] Build the package. It currently fails with the following test summary: 80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1) Failed test: 12 Non-zero exit status: 1 [Where problems could occur] I supposed this could break the build even worse. [Other Info] This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947588] Autopkgtest regression report (openssl/1.1.1l-1ubuntu1.4)
All autopkgtests for the newly accepted openssl (1.1.1l-1ubuntu1.4) for impish have finished running. The following regressions have been reported in tests triggered by the package: nagios-plugins-contrib/35.20210511ubuntu2 (ppc64el) nodejs/12.22.5~dfsg-5ubuntu1 (amd64) swupdate/2020.11-2 (ppc64el) asterisk/1:16.16.1~dfsg-2 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/impish/update_excuses.html#openssl [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: Fix Committed Status in openssl source package in Impish: Fix Committed Status in openssl source package in Jammy: Fix Committed Bug description: [Impact] The TLS test server `openssl s_server` can very easily be led into an infinite loop if configured with incompatible settings and used via DTLS. This makes it harder to test one's TLS configuration. [Test plan] In one session: $ openssl s_server -nocert -psk 01020304 -dtls1 In parallel: $ openssl s_client -dtls1 -psk 01020304 The server session will enter an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ... etc... [Where problems could occur] The patch is fairly self-contained, so regressions should only occur in the `openssl s_server` application, and not in the libssl or libcrypto libraries. However, the patch could break said server, which might be used in e.g. autopkgtests. [Original report] Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978093] Autopkgtest regression report (openssl/1.1.1l-1ubuntu1.4)
All autopkgtests for the newly accepted openssl (1.1.1l-1ubuntu1.4) for impish have finished running. The following regressions have been reported in tests triggered by the package: nagios-plugins-contrib/35.20210511ubuntu2 (ppc64el) nodejs/12.22.5~dfsg-5ubuntu1 (amd64) swupdate/2020.11-2 (ppc64el) asterisk/1:16.16.1~dfsg-2 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/impish/update_excuses.html#openssl [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1978093 Title: openssl: FTBFS due to expired certificates Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Status in openssl source package in Focal: Fix Committed Status in openssl source package in Impish: Fix Committed Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Fix Released Bug description: [Impact] Some certificates in the openssl package expired on 2022-06-01, making the test suite fail. This needs to be fixed to facilitate future security updates. [Test Plan] Build the package. It currently fails with the following test summary: 80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1) Failed test: 12 Non-zero exit status: 1 [Where problems could occur] I supposed this could break the build even worse. [Other Info] This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1978871] [NEW] apt package missing apt-auto-removal
Public bug reported: #> lsb_release -rd Description:Ubuntu 20.04.4 LTS Release:20.04 #> apt-cache policy apt apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages The /etc/kernel/postinst.d/apt-auto-removal file is supposed to be included in the apt package... #> apt-file find apt-auto-removal apt: /etc/kernel/postinst.d/apt-auto-removal open-infrastructure-system-build: /usr/share/live/build/hooks/normal/0196-remote-apt-auto-removal.hook.chroot But versions 2.0.8 and 2.0.9 do not include it... #> dpkg -L apt | fgrep -i post /etc/kernel/postinst.d #> ls /etc/kernel/postinst.d/ ./ ../ initramfs-tools* xx-update-initrd-links* zz-update-grub* Can you please rebuild this package to include the missing file? ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- 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/1978871 Title: apt package missing apt-auto-removal Status in apt package in Ubuntu: New Bug description: #> lsb_release -rd Description: Ubuntu 20.04.4 LTS Release: 20.04 #> apt-cache policy apt apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages The /etc/kernel/postinst.d/apt-auto-removal file is supposed to be included in the apt package... #> apt-file find apt-auto-removal apt: /etc/kernel/postinst.d/apt-auto-removal open-infrastructure-system-build: /usr/share/live/build/hooks/normal/0196-remote-apt-auto-removal.hook.chroot But versions 2.0.8 and 2.0.9 do not include it... #> dpkg -L apt | fgrep -i post /etc/kernel/postinst.d #> ls /etc/kernel/postinst.d/ ./ ../ initramfs-tools* xx-update-initrd-links* zz-update-grub* Can you please rebuild this package to include the missing file? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1978871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958267] Re: wpa can't connect to servers using TLS 1.1 or older
Added -proposed, updated, and eduroam is happy again. Nice to have something to tell the Ubuntu-wielding students/faculty/staff until we get 'round to upgrading our Radius servers. Thank you for the fix! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1958267 Title: wpa can't connect to servers using TLS 1.1 or older Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Jammy: Fix Committed Status in wpa package in Debian: New Bug description: * Impact wpa built with in openssl3 fails to connect to TLS 1.1 or lower server * Test case try to connect to a TLS <= 1.1 access point * Regression potential the patch lowers the security level in some situation for compatibility, it shouldn't prevent connecting to newer hardware, still try to connect to different type of wifi with different security levels --- those uses MD5-SHA1 as digest in its signature algorithm which no longer meets OpenSSL default level of security of 80 bits http://lists.infradead.org/pipermail/hostap/2022-May/040563.html Workaround are described in #22 and #36 by basically using CipherString = DEFAULT@SECLEVEL=0 which lowers the security level --- With the current jammy version of wpasupplicant (2:2.10-1), I cannot connect to the WPA Enterprise network eduroam, which is used by Universities worldwide. I get a "Connection failed" message or a request to re-enter the password. - I've re-tried the credentials: no fix ;-) - Tried a 21.10 live session on the same machine: works fine! - Manually downgraded wpasupplicant to the impish version (2:2.9.0-21build1): connected normally. - Upgraded wpasupplicant to the latest version: fails to connect again. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: wpasupplicant 2:2.10-1 ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12 Uname: Linux 5.15.0-17-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu75 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Jan 18 09:56:23 2022 InstallationDate: Installed on 2021-11-30 (48 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962135] [gstreamer1.0/focal] verification still needed
The fix for this bug has been awaiting testing feedback in the -proposed repository for focal for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository. ** Tags added: removal-candidate -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-base1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1962135 Title: [SRU] gstreamer 1.16.3 series Status in gst-plugins-bad1.0 package in Ubuntu: Fix Released Status in gst-plugins-base1.0 package in Ubuntu: Fix Released Status in gst-plugins-good1.0 package in Ubuntu: Fix Released Status in gstreamer1.0 package in Ubuntu: Fix Released Status in gst-plugins-bad1.0 source package in Focal: Fix Committed Status in gst-plugins-base1.0 source package in Focal: Fix Committed Status in gst-plugins-good1.0 source package in Focal: Fix Committed Status in gstreamer1.0 source package in Focal: Fix Committed Bug description: [ Description ] We should keep up with GStreamer's bugfix releases in the 1.16 series that 20.04 shipped with. [ QA and testing ] Play a range of videos in Totem. Play a range of audio tracks in Rhythmbox. Try to stream audio and/or video. Try to install a missing codec. In all cases, make sure that everything which worked before still works. [ Regression potential ] If one of the fixes is bad then it might break video or audio playback, or could crash any application that tries to use gstreamer. --- On ubuntu-20.04 "apt-get" default installs gstreamer version 1.16.2, though gstreamer has subsequent minor version gst-1.16.3 with fixes incorporated. Hence, Ideally default gstreamer-1.16 minor version support with ubuntu-20.04 should be upgraded to use gstreamer version 1.16.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1962135/+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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Thx for the retest! With that I would go from Incomplete back to In Progress ... ** Changed in: ubuntu-z-systems Status: Incomplete => In Progress ** Changed in: zlib (Ubuntu) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: In Progress Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: In Progress Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request:
[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla
--- Comment From i...@de.ibm.com 2022-06-15 14:00 EDT--- I don't really remember, so I retested. 20.04: 1.2.11.dfsg-2ubuntu1.3 fixes the problem (I had to install the .deb file manually with dpkg). 22.04: 1.2.11.dfsg-2ubuntu9.1 fixes the problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Incomplete Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Incomplete Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into th
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
I would like to proceed on this (to not loose to much time...) To sum things up: On top of the actual zlib fix, there is another patch 'Remove compressBound assertions. (PR #1258)' needed for htslib. Unfortunately there is a standalone 'htslib' package, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched. The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. and embedded htslib, hence does not need to be (actually can't be) patched. Due to the fact that now in total 3 packages are involved and two libraries (zlib and htslib, well and the libraries included in bedtools), this will cause a bigger transition (especially for htslib in focal, and zlib itself on all affected Ubuntu releases). (The transition(s) need to be planned here: https://people.canonical.com/~ubuntu-archive/transitions/index.html) ** Attachment added: "reverse dependencies, gathered on focal.txt" https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597497/+files/reverse%20dependencies%2C%20gathered%20on%20focal.txt ** Changed in: htslib (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Incomplete Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Incomplete Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, imp
[Touch-packages] [Bug 1978853] [NEW] Volume keys on USB keyboard do not work
Public bug reported: I use a USB keyboard plugged into a laptop running Ubuntu. The USB keyboard has volume adjustment integrated into the function row: mute is Fn + F1, decrease volume is Fn + F2, and increase volume is Fn + F3. On Ubuntu 20.04.4, I could use these keys to do volume adjustment. But, when I upgraded to Ubuntu 22.04, these keys no longer work. I also have volume keys on my laptop integrated into the function row, but the Fn key does not need to be held: mute is just the "F1" key, decrease volume is just the "F2" key, and increase volume is just the "F3" key. These keys adjust volume as expected. I tried plugging in my USB keyboard into a Macbook Pro, and I can use the keyboard to do volume adjustment as expected. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ubuntu 5481 F pulseaudio /dev/snd/pcmC0D0p: ubuntu 5481 F...m pulseaudio CasperMD5CheckResult: pass CasperVersion: 1.470 CurrentDesktop: ubuntu:GNOME Date: Wed Jun 15 17:23:53 2022 LiveMediaBuild: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Speaker, Internal Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: None of the above Title: [20HDCTO1WW, Realtek ALC298, Speaker, Internal] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/10/2017 dmi.bios.release: 1.43 dmi.bios.vendor: LENOVO dmi.bios.version: N1QET68W (1.43 ) dmi.board.asset.tag: Not Available dmi.board.name: 20HDCTO1WW dmi.board.vendor: LENOVO dmi.board.version: 0B98417 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.29 dmi.modalias: dmi:bvnLENOVO:bvrN1QET68W(1.43):bd11/10/2017:br1.43:efr1.29:svnLENOVO:pn20HDCTO1WW:pvrThinkPadT470:rvnLENOVO:rn20HDCTO1WW:rvr0B98417WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20HD_BU_Think_FM_ThinkPadT470: dmi.product.family: ThinkPad T470 dmi.product.name: 20HDCTO1WW dmi.product.sku: LENOVO_MT_20HD_BU_Think_FM_ThinkPad T470 dmi.product.version: ThinkPad T470 dmi.sys.vendor: LENOVO ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1978853 Title: Volume keys on USB keyboard do not work Status in alsa-driver package in Ubuntu: New Bug description: I use a USB keyboard plugged into a laptop running Ubuntu. The USB keyboard has volume adjustment integrated into the function row: mute is Fn + F1, decrease volume is Fn + F2, and increase volume is Fn + F3. On Ubuntu 20.04.4, I could use these keys to do volume adjustment. But, when I upgraded to Ubuntu 22.04, these keys no longer work. I also have volume keys on my laptop integrated into the function row, but the Fn key does not need to be held: mute is just the "F1" key, decrease volume is just the "F2" key, and increase volume is just the "F3" key. These keys adjust volume as expected. I tried plugging in my USB keyboard into a Macbook Pro, and I can use the keyboard to do volume adjustment as expected. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ubuntu 5481 F pulseaudio /dev/snd/pcmC0D0p: ubuntu 5481 F...m pulseaudio CasperMD5CheckResult: pass CasperVersion: 1.470 CurrentDesktop: ubuntu:GNOME Date: Wed Jun 15 17:23:53 2022 LiveMediaBuild: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Speaker, Internal Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: None of the above Title: [20HDCTO1WW, Realtek ALC298, Spe
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added: "debdiff_bedtools_jammy_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu0.1.patch" https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597489/+files/debdiff_bedtools_jammy_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu0.1.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Incomplete Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: New Status in zlib package in Ubuntu: Incomplete Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added: "debdiff_bedtools_impish_from_2.30.0+dfsg-1_to_2.30.0+dfsg-1ubuntu0.1.patch" https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597490/+files/debdiff_bedtools_impish_from_2.30.0+dfsg-1_to_2.30.0+dfsg-1ubuntu0.1.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Incomplete Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: New Status in zlib package in Ubuntu: Incomplete Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added: "debdiff_bedtools_kinetic_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu1.patch" https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597488/+files/debdiff_bedtools_kinetic_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu1.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Incomplete Status in bedtools package in Ubuntu: New Status in htslib package in Ubuntu: New Status in zlib package in Ubuntu: Incomplete Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: New Status in zlib source package in Focal: New Status in bedtools source package in Impish: New Status in htslib source package in Impish: Invalid Status in zlib source package in Impish: New Status in bedtools source package in Jammy: New Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Incomplete Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Description changed: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff + + * On top of this actual zlib fix, there is another patch needed: + 'Remove compressBound assertions. (PR #1258)' for htslib. + + * But there is a standalone 'htslib' package version, as well as a + htslib version included in (some) 'bedtools' packages. + Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] - * Ubuntu jammy, impish and focal are affected. + * Ubuntu jammy, impish and focal are affected by the zlib issue. + + * The 'htslib' version '1.13+ds' (as it is part of I, J and K), + already includes the patch, + hence only htslib '1.10.2' in focal needs to be patched. + + * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), + requires the patch, + but version '2.27.1+dfsg' bedtools in focal does not incl. an + embedded htslib, hence does not need to be (actually can't be) + patched. + + * Patched version of the affected htslib and bedtools packages + are build and also available at this PPA: + https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 + __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. Reproduction: z15 only: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } ** Also affects: htslib (Ubuntu) Importance: Undecided Status: New ** Changed in: htslib (Ubuntu Impish) Status: New => Invalid ** Changed in: htslib (Ubuntu Jammy) Status: New => Invalid ** Changed in: bedtools (Ubuntu Focal)
[Touch-packages] [Bug 1977968] Re: Security update tracking bug
This bug was fixed in the package bluez - 5.48-0ubuntu3.9 --- bluez (5.48-0ubuntu3.9) bionic-security; urgency=medium * SECURITY UPDATE: various security improvements (LP: #1977968) - debian/patches/avdtp-security.patch: check if capabilities are valid before attempting to copy them in profiles/audio/avdtp.c. - debian/patches/avdtp-security-2.patch: fix size comparison and variable misassignment in profiles/audio/avdtp.c. - debian/patches/avrcp-security.patch: make sure the number of bytes in the params_len matches the remaining bytes received so the code don't end up accessing invalid memory in profiles/audio/avrcp.c. - No CVE numbers -- Marc Deslauriers Wed, 08 Jun 2022 07:19:20 -0400 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1977968 Title: Security update tracking bug Status in bluez package in Ubuntu: Fix Released Bug description: This bug is to track the security update that will contain these possibly security-relevant commits: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=e2b0f0d8d63e1223bb714a9efb37e2257818268b https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7a80d2096f1b7125085e21448112aa02f49f5e9a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1977968/+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 1977968] Re: Security update tracking bug
This bug was fixed in the package bluez - 5.53-0ubuntu3.6 --- bluez (5.53-0ubuntu3.6) focal-security; urgency=medium * SECURITY UPDATE: various security improvements (LP: #1977968) - debian/patches/avdtp-security.patch: check if capabilities are valid before attempting to copy them in profiles/audio/avdtp.c. - debian/patches/avdtp-security-2.patch: fix size comparison and variable misassignment in profiles/audio/avdtp.c. - debian/patches/avrcp-security.patch: make sure the number of bytes in the params_len matches the remaining bytes received so the code don't end up accessing invalid memory in profiles/audio/avrcp.c. - No CVE numbers -- Marc Deslauriers Wed, 08 Jun 2022 07:09:00 -0400 ** Changed in: bluez (Ubuntu) Status: New => Fix Released ** Changed in: bluez (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1977968 Title: Security update tracking bug Status in bluez package in Ubuntu: Fix Released Bug description: This bug is to track the security update that will contain these possibly security-relevant commits: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=e2b0f0d8d63e1223bb714a9efb37e2257818268b https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7a80d2096f1b7125085e21448112aa02f49f5e9a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1977968/+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 1977982] Re: Please merge keyutils 1.6.1-3 (main) from Debian unstable (main)
This bug was fixed in the package keyutils - 1.6.1-3ubuntu1 --- keyutils (1.6.1-3ubuntu1) kinetic; urgency=medium * Merge from Debian unstable (LP: #1977982). Remaining changes: - d/p/apply-ttl-records.patch: Add patch to apply default TTL to records obtained from getaddrinfo(). (LP: #1962453) Dropped patches: - d/p/private-priv.patch: This patch was fixing a FTBFS issue for nuxwdog which is no longer present in the archive. Other packages that build-depend on libkeyutils-dev do not FTBFS in Debian currently ; where the patch is not applied. keyutils (1.6.1-3) unstable; urgency=medium * Bump Standards-Version to 4.6.0 (no changes needed) * Bump debhelper compatibility to 13 * Drop cifs.patch (obsolete) keyutils (1.6.1-2ubuntu3) jammy; urgency=medium * d/p/apply-default-ttl-to-records.patch: Add patch to apply default TTL to records obtained from getaddrinfo(). (LP: #1962453) keyutils (1.6.1-2ubuntu2) impish; urgency=medium * No-change rebuild to build packages with zstd compression. -- Olivier Gayot Wed, 08 Jun 2022 17:25:33 +0200 ** Changed in: keyutils (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to keyutils in Ubuntu. https://bugs.launchpad.net/bugs/1977982 Title: Please merge keyutils 1.6.1-3 (main) from Debian unstable (main) Status in keyutils package in Ubuntu: Fix Released Bug description: The Ubuntu delta contains two patches: * d/p/private-priv.patch: This patch was applied in Ubuntu to fix a FTBFS issue on nuxwdog. nuxwdog was a C++ project and would include the header file from libkeyutils-dev. Unfortunately, the header file contains variables named "private" - which is a keyword in C++ but not in C. The last version of nuxwdog from the archive is in Bionic so I am tempted to drop this patch. The bug report on Debian was closed/not-fixed when nuxwdog was removed from the archive: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923011 If we drop this, there is a chance, however, that other packages would FTBFS if they build-depends on libkeyutils-dev and include the C header in C++ code. Here is the list of packages that build-depends on libkeyutils-dev: * bcachefs-tools * ceph * cifs-utils * ecryptfs-utils * gdm3 * gssproxy * ima-evm-utils * kafs-client * krb5 * kstart * ndctl * nfs-utils * python-keyutils * sssd * stress-ng All these packages are in Debian unstable today and are not FTBFS, so I'd assume it's fine to drop the patch. * d/p/apply-ttl-to-records.patch: This patch was applied recently (from upstream) to fix #1962453. I think we need to keep this patch and I'm considering forwarding it to Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keyutils/+bug/1977982/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: mariadb-10.6 (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: mariadb-10.6 (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: mariadb-10.6 (Ubuntu Jammy) Status: New => Triaged ** Changed in: mariadb-10.6 (Ubuntu Jammy) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: New Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1977627] Re: New upstream microrelease 2.5.12
As usual with non-security updates, we use the results of autopkgtest in order to perform the verification. In this case, all tests succeeded for openldap in Jammy. Therefore, tagging as verification-done-jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1977627 Title: New upstream microrelease 2.5.12 Status in openldap package in Ubuntu: New Status in openldap source package in Jammy: Fix Committed Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.12. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/LSEQKADYZFFMZJGPEVBRR3OVOY4IOGRA/ * In particular, this release includes the fix for CVE-2022-29155, but since the CVE has already been addressed by the currently OpenLDAP version in Jammy (2.5.11+dfsg-1~exp1ubuntu3.1), this does not classify as a security upload. [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/pipelines/4298 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/5ZJEOQSVFQBG5TRLAAF6S5M3VRJH5IAV/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in bileto and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: https://launchpadlibrarian.net/606922528/buildlog_ubuntu-jammy- amd64.openldap_2.5.12+dfsg-0ubuntu0.22.04.1_BUILDING.txt.gz * Bileto ticket: https://bileto.ubuntu.com/#/ticket/4868 [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - CVE-2022-29155, which has already been addressed in Jammy. Current versions in supported releases that got updates: openldap | 2.5.11+dfsg-1~exp1ubuntu3.1 | jammy-updates | source Special cases: - None. Previous MREs for OpenLDAP: - None so far. As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1977627/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
Tim Richardson, I recognize your effort and contribution to solve the problem, but without my comment in #33, where I must say I were not very nice, you would not have clarified that cgroups v2 was enabled again. Maybe you stated that with nomachine community, but not here. Not stated before my comment #33 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
I have been reading a bit more. I'm starting to form the impression that this problem may originate from the way our various remote solutions are logging in. They may not be doing it the proper modern login-systemd way. This would mean that nomachine, x2go are both wrong. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Hello, any idea when the fix will land in jammy? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977645] Re: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail
Ubuntu 20.04 is also affected by this bug in the same way. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1977645 Title: python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail Status in gpgme1.0 package in Ubuntu: Confirmed Bug description: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary-equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1977645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
And let us hope that someone who can fix it steps up and fixes it properly because right now, ubuntu 22.04 and derivatives are unfit for remote desktop deployments. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
I'm just an ordinary user trying to get this working and volunteering what I learn, so bear that in mind. I have no real clue about what the problem is and I still don't understand where in the session start process DBUS_SESSION_BUS_ADDRESS is set and why we get a wrong value when starting sessions with our remote access. I sent my workaround to nomachine since it has some advantages over their current solution of disabling cgroupv2. They said it works for them, and they have altered their tech note to say the node.cfg could also be: DefaultDesktopCommand "env DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4" I think you will recognise how to apply that. This seems to allow only one session per user. let me know if it works. I remember now I setup "loginctl enable- linger", which may or may not be helping my solution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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 1978093] Re: openssl: FTBFS due to expired certificates
Accepting this into Bionic blocked on bug 1940141, and it's further noted there that there's an openssl security update expected on 21 June, so it's probably best to rebase on that when it arrives. -- 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/1978093 Title: openssl: FTBFS due to expired certificates Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Status in openssl source package in Focal: Fix Committed Status in openssl source package in Impish: Fix Committed Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Fix Released Bug description: [Impact] Some certificates in the openssl package expired on 2022-06-01, making the test suite fail. This needs to be fixed to facilitate future security updates. [Test Plan] Build the package. It currently fails with the following test summary: 80-test_ssl_new.t(Wstat: 256 Tests: 30 Failed: 1) Failed test: 12 Non-zero exit status: 1 [Where problems could occur] I supposed this could break the build even worse. [Other Info] This currently prevents 3.0.2-0ubuntu1.3 in Jammy from publication. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1978093/+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 1969901] Re: network-manager fails to renew ipv6 address
Thank you for the comments. These seem like good ideas, but need details before they are actionable. I think this update is still blocked on having a specific, step-by-step test plan please. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1969901 Title: network-manager fails to renew ipv6 address Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Incomplete Bug description: [Impact] * This affects Ubuntu 18.04 where Network Manager version 1.10.6 is used. * Network manager might kill dhclient(6) and fail to start it again causing the IPv6 address to be lost on a network that uses mixed IPv4/IPV6. The network status will still be seen as online in gnome since ipv4 is still active. The user then have to manually remove the dhcpv6 lease files and restart ipv6 connection/restart network manager to regain IPv6 connectivity. * This is a cherry-pick from Network manager 1.10.8 (Ubuntu's version is based on 1.10.6): https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/7fbbe7ebee99785e38d39c37e515a64a28edef0f * Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=783391 [Test Plan] * The exact conditions for reproducing this bug on mixed IPv4/IPv6 networks are not known but includes using both IPv4 and IPv6, both using dhcp. [Where problems could occur] * The change is in the dchp lease expiration handling so verify that there is no regression in dhcp renewals on different type of configuration include IPv6 [Other Info] * We have tested this patch on a couple of clients where we have seen this this problem. If this patch is feasible to include in Ubuntu 18.04 we could request more users to test. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1969901/+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 1974223] Re: FTBFS and autopkgtest failure since changes in apt for automatic kernel removal
What's the current status of this please? Julian's last comment suggests that there's a problem? I see an upload in the queue for Bionic, but not for Focal. What's the status in Focal? Is this something that can be staged in proposed, or do you need it in the updates pockets, and if so, why? ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: New => Incomplete ** Changed in: unattended-upgrades (Ubuntu Focal) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1974223 Title: FTBFS and autopkgtest failure since changes in apt for automatic kernel removal Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Bionic: Incomplete Status in unattended-upgrades source package in Focal: Incomplete Status in unattended-upgrades package in Debian: Fix Released Bug description: [Impact] Since the following changes in apt have landed in focal-updates (and is currently in bionic-proposed), unattended-upgrades FTBFS and fails autopkgtest on both series: * Revert "Protect currently running kernel at run-time" * Backport Determine autoremovable kernels at run-time (LP: #1615381) as of 2.4.5; including the change to only protect two kernels, not last installed one (LP: #1968154) == FAIL: test_remove_unused_dependencies_new_unused_only (__main__.TestRemoveUnused) -- Traceback (most recent call last): File "./test_remove_unused.py", line 165, in test_remove_unused_dependencies_new_unused_only haystack)) AssertionError: False is not true : Can not find 'Removing unused kernel packages: linux-image-4.05.0-1021-kvm [Test plan] 1. focal: * run autopkgtest against -updates: $ autopkgtest unattended-upgrades --apt-upgrade --apt-pocket=updates --test-name run-tests -- * try to build the package 2. bionic: * run autopkgtest against -proposed: $ autopkgtest unattended-upgrades --apt-upgrade --apt-pocket=proposed --test-name run-tests -- * try to build the package [Where problems could occur] * The fix only affects the test-suite (that runs both at build time & autopkgtest time) so the impact should be minimal. Something wrong in the patch would make the unattended package FTBFS or fail autopkgtest but it is already failing ATM. * The new tests dependency on apt can trigger more autopkgtest runs. Since unattended-upgrades has a non-trivial autopkgtest suite, this can have a slight impact on the queues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1974223/+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 1978816] [NEW] sshd: ClientAliveCountMax=0 not honoured as expected
Public bug reported: $ apt-cache policy openssh-server openssh-server: Installed: 1:8.2p1-4ubuntu0.4 Candidate: 1:8.2p1-4ubuntu0.4 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.4 LTS Release:20.04 Codename: focal After upgrading from 'bionic' the openssh ClientAlive* parameters are not functioning as expected in sshd: /etc/ssh/sshd_config:ClientAliveInterval 900 /etc/ssh/sshd_config:ClientAliveCountMax 0 The expected behaviour is that after 900s with no traffic in the session the server terminates the connection. There appears to be a custom patch in the package which changes this: - sshd(8): Make ClientAliveCountMax=0 have sensible semantics: it will now disable connection killing entirely rather than the current behaviour of instantly killing the connection after the first liveness test regardless of success. It is unclear why this is a beneficial change in the default behaviour of sshd. If the user doesn't want the session disconnected then they should set ClientAliveInterval=0. It also defeats our requirement to have idle ssh sessions terminated when nothing has been done for 15 minutes. It is tempting to mark this as a security issue due to unexpected change in behaviour and the fact it would leave idle sessions open whereas a vanilla ssh package would close them. ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- 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/1978816 Title: sshd: ClientAliveCountMax=0 not honoured as expected Status in openssh package in Ubuntu: New Bug description: $ apt-cache policy openssh-server openssh-server: Installed: 1:8.2p1-4ubuntu0.4 Candidate: 1:8.2p1-4ubuntu0.4 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.4 LTS Release:20.04 Codename: focal After upgrading from 'bionic' the openssh ClientAlive* parameters are not functioning as expected in sshd: /etc/ssh/sshd_config:ClientAliveInterval 900 /etc/ssh/sshd_config:ClientAliveCountMax 0 The expected behaviour is that after 900s with no traffic in the session the server terminates the connection. There appears to be a custom patch in the package which changes this: - sshd(8): Make ClientAliveCountMax=0 have sensible semantics: it will now disable connection killing entirely rather than the current behaviour of instantly killing the connection after the first liveness test regardless of success. It is unclear why this is a beneficial change in the default behaviour of sshd. If the user doesn't want the session disconnected then they should set ClientAliveInterval=0. It also defeats our requirement to have idle ssh sessions terminated when nothing has been done for 15 minutes. It is tempting to mark this as a security issue due to unexpected change in behaviour and the fact it would leave idle sessions open whereas a vanilla ssh package would close them. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1978816/+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 1864215] Re: Please add webp loader to gdk-pixbuf
** Tags added: dt-394 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdk-pixbuf in Ubuntu. https://bugs.launchpad.net/bugs/1864215 Title: Please add webp loader to gdk-pixbuf Status in gdk-pixbuf: Fix Released Status in gdk-pixbuf package in Ubuntu: Confirmed Status in gdk-pixbuf package in Baltix: Triaged Status in Debian: New Bug description: Attempting to load a webp image -- for instance, https://images.theweek.com/sites/default/files/styles/tw_image_9_4/public/FKK78W.jpg.webp or https://cdn.vox-cdn.com/thumbor/2YtWB5zH7sPycyc0FYv3JSB6SFw=/60x0:1140x720/920x613/filters:focal(60x0:1140x720):format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/49663815/timburton.0.0.jpg -- in a gdk-pixbuf app results in a "Couldn’t recognize the image file format" error. Bug 1318327 covers this issue in eye of gnome, and bug 1407644 in libwebp, but isn't this really a gdk-pixbuf issue? If it really does belong to libwebp, my apologies, please dup this bug to 1407644 (I'm confident it doesn't belong to eog since I don't use that program; I have other programs that use libgdk-pixbuf). You can probably use eog to test this, or run /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders | grep -i webp (I assume the loader would mention webp if there was a loader for it). I have these packages installed in addition to libgdk-pixbuf2.0-0: libwebp-dev libwebp6 libwebpdemux2 libwebpmux3 webp. file recognizes the format: $ file /tmp/FKK78W.jpg.webp /tmp/FKK78W.jpg.webp: RIFF (little-endian) data, Web/P image, VP8 encoding, 1200x533, Scaling: [none]x[none], YUV color, decoders should clamp ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: libgdk-pixbuf2.0-0 2.40.0+dfsg-1build1 ProcVersionSignature: Ubuntu 5.3.0-40.32-generic 5.3.18 Uname: Linux 5.3.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8.4 Architecture: amd64 Date: Fri Feb 21 08:48:36 2020 InstallationDate: Installed on 2019-10-10 (133 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1) SourcePackage: gdk-pixbuf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gdk-pixbuf/+bug/1864215/+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 1969896] Re: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched
** Tags added: dt-392 -- 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/1969896 Title: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched Status in apparmor package in Ubuntu: Confirmed Status in evince package in Ubuntu: In Progress Bug description: Just switched from Ubuntu 20.04 to 22.04 and realized that Document Viewer no longer open on the last viewed page and doesn't remember the side pane preference even after using the "Save Current Settings as Default" option. Kindly advise ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: evince 42.1-3 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Apr 22 15:58:50 2022 InstallationDate: Installed on 2022-03-19 (34 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: evince UpgradeStatus: Upgraded to jammy on 2022-04-21 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1969896/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
Tim, yes it works adding the environment variable, but you wrote "I should have been clearer" in comment 35, but that is wrong, you should at least had mentioned that you did enabled the cgroupsv2, and from comment 27 to comment 32, there are no mention about reverting systemd.unified_cgroup_hierarchy=0 to 1. Should I say I am sorry for my misunderstood? Well for me it was really hard to read on without this details: cgroupsv2 was enabled. Without neither mention that "detail", it follow my interpretation as a spam/off-topic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958267] Re: wpa can't connect to servers using TLS 1.1 or older
I enabled propsed and updated wpasupplicant to 2:2.10-6ubuntu2 and I'm now able to connect to the corporate WiFi network again. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1958267 Title: wpa can't connect to servers using TLS 1.1 or older Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Jammy: Fix Committed Status in wpa package in Debian: New Bug description: * Impact wpa built with in openssl3 fails to connect to TLS 1.1 or lower server * Test case try to connect to a TLS <= 1.1 access point * Regression potential the patch lowers the security level in some situation for compatibility, it shouldn't prevent connecting to newer hardware, still try to connect to different type of wifi with different security levels --- those uses MD5-SHA1 as digest in its signature algorithm which no longer meets OpenSSL default level of security of 80 bits http://lists.infradead.org/pipermail/hostap/2022-May/040563.html Workaround are described in #22 and #36 by basically using CipherString = DEFAULT@SECLEVEL=0 which lowers the security level --- With the current jammy version of wpasupplicant (2:2.10-1), I cannot connect to the WPA Enterprise network eduroam, which is used by Universities worldwide. I get a "Connection failed" message or a request to re-enter the password. - I've re-tried the credentials: no fix ;-) - Tried a 21.10 live session on the same machine: works fine! - Manually downgraded wpasupplicant to the impish version (2:2.9.0-21build1): connected normally. - Upgraded wpasupplicant to the latest version: fails to connect again. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: wpasupplicant 2:2.10-1 ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12 Uname: Linux 5.15.0-17-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu75 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Jan 18 09:56:23 2022 InstallationDate: Installed on 2021-11-30 (48 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1746419] Re: bond parameters are not changed by 'netplan apply'
This is still an issue. I like the idea of deleting the bond (e.g. "networkctl delete bond0" during the "netplan apply" call. But as stated before by daxtens, we need to make sure not to bring down critical interfaces, that might be in use. We could either only apply this only to interfaces, that are not marked as "critical: true" in netplan or hide it behind a "--force" parameter to "netplan apply". We should also investigate if there might be other options in more recent versions of systemd-networkd to make it apply new bond parameters without bringing down the interface. Closing the "nplan" component, as that package is no more in any recent series of Ubuntu. ** Changed in: netplan Status: Confirmed => Triaged ** Changed in: netplan Importance: Undecided => Medium ** Changed in: nplan (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1746419 Title: bond parameters are not changed by 'netplan apply' Status in netplan: Triaged Status in nplan package in Ubuntu: Invalid Status in systemd package in Ubuntu: Won't Fix Bug description: I have a yaml file as follows: network: version: 2 ethernets: bonddevs: match: name: ens[78] bonds: bond0: interfaces: [bonddevs] parameters: mode: active-backup mii-monitor-interval: 1 addresses: - 10.10.10.1/24 Say I decide that 1s is too frequent for the MII interval, and I want to change the interval to 2s. If I change that in the yaml, then run # netplan generate # netplan apply # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)" MII Polling Interval (ms): 1000 In other words, the change has not been applied. Running netplan --debug apply prints: DEBUG:device bond0 operstate is up, not replugging So I wondered if bringing the bond down would help. It does not: # ip link set dev bond0 down # netplan apply # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)" MII Polling Interval (ms): 1000 However, deleting the link works: # ip link del dev bond0 # netplan apply # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)" MII Polling Interval (ms): 2000 This is counter-intuitive behaviour. Ideally, I would like a regular netplan apply to work without deleting the bond. However, a changed to the docs to make this clear would be OK. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: nplan 0.32~17.10.1 ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13 Uname: Linux 4.13.0-32-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 Date: Wed Jan 31 05:47:42 2018 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: nplan UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1746419/+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 1738058] Re: vlan usage requires an intermediate step
This seems to be working nowadays. I cannot reproduce using the config provided in the description: $ netplan apply $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: vlan10@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff inet 10.0.0.5/24 brd 10.0.0.255 scope global vlan10 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fef5:92b3/64 scope link tentative valid_lft forever preferred_lft forever 3: vlan1@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff inet 192.168.0.10/23 brd 192.168.1.255 scope global vlan1 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fef5:92b3/64 scope link tentative valid_lft forever preferred_lft forever 84: eth0@if85: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::216:3eff:fef5:92b3/64 scope link valid_lft forever preferred_lft forever $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 vlan10 vlan routableconfigured 3 vlan1 vlan routableconfigured 84 eth0 etherroutableconfigured 4 links listed. Please re-open if this is still an issue. ** Changed in: nplan (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1738058 Title: vlan usage requires an intermediate step Status in nplan package in Ubuntu: Won't Fix Status in systemd package in Ubuntu: Invalid Bug description: If I try to apply vlans directly: network: version: 2 renderer: networkd ethernets: eth0: {} vlans: vlan1: id: 1 link: eth0 addresses: [ 192.168.0.10/23 ] vlan10: id: 10 link: eth0 addresses: [ 10.0.0.5/24 ] The vlan devices never come up, they are left in degraded state by networkd. If I define an address for eth0, then eth0 and all of the vlans will have the same address. Needless to say, this doesn't work. If I use an intermediary device instead, such as a bond: network: version: 2 renderer: networkd ethernets: eth0: {} bonds: vmaster: interfaces: [ eth0 ] vlans: vlan1: id: 1 link: vmaster addresses: [ 192.168.0.10/23 ] vlan10: id: 10 link: vmaster addresses: [ 10.0.0.5/24 ] Then the vlans are correctly applied and brought up by systemd. I think this is either a systemd bug or a netplan bug; it's possible we don't generate the config quite in the way that systemd expects it (even though it looks straightforward enough). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1738058/+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 1713226] Re: systemd-networkd messes up networking
Netplan generates configuration snippets to make sure an interface is only handled by the backend renderer (networking-daemon: sd-networkd or NetworkManager) that is instructed to control that interface nowadays. This logic has been improved recently: https://github.com/canonical/netplan/pull/276 Please re-open if this is still an issue. ** Changed in: nplan (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1713226 Title: systemd-networkd messes up networking Status in ifupdown package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in nplan package in Ubuntu: Won't Fix Status in systemd package in Ubuntu: Won't Fix Bug description: Since systemd-234-2ubuntu8 systemd-networkd is enabled by default. This causes problems existing configurations ex1: if the network has ipv6 enables (the host recieves a router advertisement), networkmanager does not configure the network anymore so you get only ipv6 and no ipv4 connections (since systemd-networkd seems to bring only the link up) ex2: if you use systemd-nspawn and configured static ip addresses in /etc/network/interfaces, systemd-networkd adds a dhcp obtained address on the host0 adapter and a 169.254 address For the average user both is not expected, so my solution was systemctl disable systemd-networkd, but since you seem to insist having this enabled, it must be made sure systemd-networkd does not touch existing configurations. My suggestion is: 1) if /etc/network/interfaces contains anything other than lo -> do not enable systemd-networkd 2) if network-manager is enabled, systemd-networkd must be disabled and vice versa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1713226/+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 1970144] Re: [vmwgfx] Qt Creator windows don't render correctly, VMware 16, Ubuntu 22.04
See also https://gitlab.gnome.org/GNOME/mutter/-/issues/2307 ** Bug watch added: gitlab.gnome.org/GNOME/mutter/-/issues #2307 https://gitlab.gnome.org/GNOME/mutter/-/issues/2307 ** Also affects: mutter via https://gitlab.gnome.org/GNOME/mutter/-/issues/2307 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1970144 Title: [vmwgfx] Qt Creator windows don't render correctly, VMware 16, Ubuntu 22.04 Status in Mutter: Unknown Status in mesa package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Confirmed Status in qtbase-opensource-src package in Ubuntu: Confirmed Bug description: xdpyinfo name of display::0 version number:11.0 vendor string:The X.Org Foundation vendor release number:12201001 X.Org version: 1.22.1.1 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: None number of extensions:23 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DRI3 GLX Generic Event Extension MIT-SHM Present RANDR RECORD RENDER SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:3838x1781 pixels (1015x471 millimeters) resolution:96x96 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x2bb depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x43 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store WHEN MAPPED, save-unders NO largest cursor:3838x1781 current input event mask:0xda0030 EnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Apr 25 09:25:33 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller]) Subsystem: VMware SVGA II Adapter [15ad:0405] InstallationDate: Installed on 2022-04-25 (0 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: VMware, Inc. VMware Virtual Platform ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-25-generic root=UUID=e6bcbb51-635a-42a1-ab99-75af8c14475f ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet splash SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/12/2020 dmi.bios.release: 4.6 dmi.bios.vendor: Phoenix Technologies LTD dmi.bios.version: 6.00 dmi.board.name: 440BX Desktop Reference Platform dmi.board.vendor: Intel Corporation dmi.board.version: None dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 1 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.ec.firmware.release: 0.0 dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/12/2020:br4.6:efr0.0:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku: dmi.product.name: VMware Virtual Platform dmi.product.version: None dmi.sys.vendor: VMware, Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2 version.libgl1-mesa-glx: libgl1-me
[Touch-packages] [Bug 1977764] Re: kernel modules "zstd" and "z3fold" missing.
** Changed in: linux-raspi (Ubuntu Jammy) Status: New => Invalid ** Changed in: linux-raspi (Ubuntu Kinetic) Status: New => Invalid -- 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/1977764 Title: kernel modules "zstd" and "z3fold" missing. Status in linux-raspi package in Ubuntu: Invalid Status in ubuntu-settings package in Ubuntu: New Status in linux-raspi source package in Jammy: Invalid Status in ubuntu-settings source package in Jammy: New Status in linux-raspi source package in Kinetic: Invalid Status in ubuntu-settings source package in Kinetic: New Bug description: The modules "zstd" and "z3fold" are missing despite being configured for zswap in "/boot/firmware/cmdline.txt." Messages appear on boot display that state they do not exist and so instead use compressor "lzo" and pool "zbud". Ubuntu version is 22.04 LTS flashed from the official image. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-1008-raspi 5.15.0-1008.8 ProcVersionSignature: Ubuntu 5.15.0-1008.8-raspi 5.15.30 Uname: Linux 5.15.0-1008-raspi aarch64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: arm64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jun 6 17:29:00 2022 ImageMediaBuild: 20220419 SourcePackage: linux-raspi UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1977764/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
Tim, Two "Thank-you"s for you: 1. "spamming" elsewhere and here. Indeed, I got redirected here after I saw your comments at snapcraft forum 2. Correctly specifying the bus address for the session by setting DBUS_SESSION_BUS_ADDRESS. This worked like magic! My Ubuntu 22.04 running KDE Plasma was almost unusable over x2go. I can't thank you enough! This is the exact issue that appears when running any confined snap over x2go (or VNC as reported by others) ``` /user.slice/user-1000.slice/session-1.scope is not a snap cgroup ``` As it turned out, it was snapd not finding the bus path. For anyone looking for a quick fix, apply Tim's fix to your ~/.profile and you are good to go. Some snaps (like Firefox) requires re-installation to work. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in snapd package in Debian: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/+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