[Touch-packages] [Bug 1965439] Re: [SRU] kdesu fails to authenticate with sudo from Jammy
BlackMage, the publishing history page suggests the fix was published a year earlier: https://launchpad.net/ubuntu/+source/kdesu/5.92.0-0ubuntu1.1 What is the output of: apt policy libkf5su-data namei -l /etc/sudoers.d/kdesu-sudoers Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1965439 Title: [SRU] kdesu fails to authenticate with sudo from Jammy Status in kdesu package in Ubuntu: Fix Released Status in kubuntu-settings package in Ubuntu: Fix Released Status in sudo package in Ubuntu: Won't Fix Status in ubuntustudio-default-settings package in Ubuntu: Fix Released Status in kdesu source package in Jammy: Fix Released Status in kubuntu-settings source package in Jammy: In Progress Status in sudo source package in Jammy: Won't Fix Status in ubuntustudio-default-settings source package in Jammy: Fix Released Status in kdesu source package in Kinetic: Fix Released Status in kubuntu-settings source package in Kinetic: Fix Released Status in sudo source package in Kinetic: Won't Fix Status in ubuntustudio-default-settings source package in Kinetic: Fix Released Status in kdesu package in Debian: Fix Released Bug description: kdesu fails to authenticate with sudo from Jammy. See upstream bug: KDE bug: https://bugs.kde.org/show_bug.cgi?id=452532 Examples: Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. On entering the correct password authentication is refused, stating that possibly an incorrect password has been entered. It appears that kdesu fails to cope with the sudo config change in this commit: https://salsa.debian.org/sudo- team/sudo/-/commit/59db341d46aa4c26b54c1270e69f2562e7f3d751 kdesu was fixed in Debian with: https://tracker.debian.org/news/1330116/accepted-kdesu-5940-2-source- into-unstable/ and fixed in kinetic with: https://launchpad.net/ubuntu/+source/kdesu/5.94.0-0ubuntu2 The issue can be worked around by adding /etc/sudoers.d/kdesu-sudoers with the contents Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty [Impact] * Users are unable to authenticate to and launch applications via kdesu. * This should be backported to restore functionality that users expect. [Test Plan] * Launch Kubuntu driver manager from system setting, launching ksystemlog from the main menu, or trying to run krusader root mode option via its 'Tools > Start Krusader Root Mode' menu entry. Assuming that the current user is a member of the sudo group. * Confirm that the application authentcate and launch as successfully as in previous releases. [Where problems could occur] * While this update only returns sudo to its default behaviour (used in previous releases and virtually all other distributions) for kdesu, care should be taken to test some other applications that seek root permissions to confirm that no unexpected consequences occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdesu/+bug/1965439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912911] Re: When printing with my Brother hl-2170w printer I keep getting an invalid page range error on a blank page, after the desired pages are printed
I also observed this issue on my laptop with 20.04. I created a patched version in this PPA[1] and it seems the issue is resolved with the patch mentioned in comment #5. If anyone can confirm the patched version does help, I'll submit the patch for SRU. [1] https://launchpad.net/~robertliu/+archive/ubuntu/lp-1912911 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1912911 Title: When printing with my Brother hl-2170w printer I keep getting an invalid page range error on a blank page, after the desired pages are printed Status in cups package in Ubuntu: Confirmed Bug description: When I run uname -a, this is basically what I get: "5.8.0-38-generic #43~20.04.1-Ubuntu SMP Tue Jan 12 16:39:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux" apt-cache policy cups gives me the following: cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.3.1-9ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages === 4 and 5 are being answered together... Before the upgrade, I was able to print one or more pages, and not see the extra error page. This is the desired behavior. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: cups 2.3.1-9ubuntu1.1 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 23 13:15:24 2021 InstallationDate: Installed on 2020-12-21 (33 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Lpstat: device for SCRIBE: dnssd://Brother%20HL-2170W%20series._pdl-datastream._tcp.local/ MachineType: Dell Inc. Inspiron 7773 Papersize: letter PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/SCRIBE.ppd'] failed with exit code 2: grep: /etc/cups/ppd/SCRIBE.ppd: Permission denied ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-38-generic root=UUID=9899e123-f378-4328-a399-78cd6361f58e ro quiet splash resume=UUID=46e80ad1-16de-4fdf-b1f7-96f4f58b1c57 SourcePackage: cups UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/14/2017 dmi.bios.release: 1.2 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.2.1 dmi.board.name: 0R58C3 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.2.1:bd09/14/2017:br1.2:svnDellInc.:pnInspiron7773:pvr:rvnDellInc.:rn0R58C3:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 7773 dmi.product.sku: 0809 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1912911/+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 2043753] [NEW] package libnih1 1.0.3-6ubuntu2 failed to install/upgrade: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih1 whi
Public bug reported: was installing upgrade to ubuntu 20.04 and system reported crash. no visible signs other the message appeared. Upgrade continued for a while and then terminated. I had libreoffice writer open at the time of the error. ProblemType: Package DistroRelease: Ubuntu 22.04 Package: libnih1 1.0.3-6ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-166.183-generic 5.4.252 Uname: Linux 5.4.0-166-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 16 20:23:24 2023 DuplicateSignature: package:libnih1:1.0.3-6ubuntu2 Unpacking libnetpbm10 (2:10.0-15.4) over (2:10.0-15.3build1) ... dpkg: error processing archive /tmp/apt-dpkg-install-eWw3bF/0718-libnih-dbus1_1.0.3-12build1_amd64.deb (--unpack): package libnih-dbus1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih-dbus1 which has multiple installed instances ErrorMessage: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih1 which has multiple installed instances InstallationDate: Installed on 2014-04-03 (3514 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.1ubuntu2.2 apt 2.4.11 SourcePackage: libnih Title: package libnih1 1.0.3-6ubuntu2 failed to install/upgrade: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih1 which has multiple installed instances UpgradeStatus: Upgraded to jammy on 2023-11-17 (0 days ago) ** Affects: libnih (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package jammy need-duplicate-check -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnih in Ubuntu. https://bugs.launchpad.net/bugs/2043753 Title: package libnih1 1.0.3-6ubuntu2 failed to install/upgrade: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co- installable with libnih1 which has multiple installed instances Status in libnih package in Ubuntu: New Bug description: was installing upgrade to ubuntu 20.04 and system reported crash. no visible signs other the message appeared. Upgrade continued for a while and then terminated. I had libreoffice writer open at the time of the error. ProblemType: Package DistroRelease: Ubuntu 22.04 Package: libnih1 1.0.3-6ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-166.183-generic 5.4.252 Uname: Linux 5.4.0-166-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 16 20:23:24 2023 DuplicateSignature: package:libnih1:1.0.3-6ubuntu2 Unpacking libnetpbm10 (2:10.0-15.4) over (2:10.0-15.3build1) ... dpkg: error processing archive /tmp/apt-dpkg-install-eWw3bF/0718-libnih-dbus1_1.0.3-12build1_amd64.deb (--unpack): package libnih-dbus1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih-dbus1 which has multiple installed instances ErrorMessage: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih1 which has multiple installed instances InstallationDate: Installed on 2014-04-03 (3514 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.1ubuntu2.2 apt 2.4.11 SourcePackage: libnih Title: package libnih1 1.0.3-6ubuntu2 failed to install/upgrade: package libnih1:amd64 (1.0.3-12build1) with field 'Multi-Arch: no' is not co-installable with libnih1 which has multiple installed instances UpgradeStatus: Upgraded to jammy on 2023-11-17 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnih/+bug/2043753/+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 2021523] Re: totem displays "Unable to play the file" dialog for a video it can play
Same obs. but with meta/x-gst-fourcc-mett. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gstreamer1.0 in Ubuntu. https://bugs.launchpad.net/bugs/2021523 Title: totem displays "Unable to play the file" dialog for a video it can play Status in gstreamer1.0 package in Ubuntu: Confirmed Bug description: I have an MP4 video file from a GoPro camera, and when I try to play it with totem, it displays a "Unable to play the file" dialog complaining about missing gstreamer elements (see attachment); totem prints the following on stderr: ** Message: 11:46:33.328: Missing plugin: gstreamer|1.0|totem|meta/x-gst-fourcc-fdsc decoder|decoder-meta/x-gst-fourcc-fdsc (meta/x-gst-fourcc-fdsc decoder) ** Message: 11:46:33.329: Missing plugin: gstreamer|1.0|totem|meta/x-gst-fourcc-gpmd decoder|decoder-meta/x-gst-fourcc-gpmd (meta/x-gst-fourcc-gpmd decoder) ** Message: 11:46:33.329: Missing plugin: gstreamer|1.0|totem|GStreamer element vaapipostproc|element-vaapipostproc (GStreamer element vaapipostproc) (totem:574404): GStreamer-CRITICAL **: 11:46:33.330: Trying to dispose element queue0, but it is in READY instead of the NULL state. You need to explicitly set elements to the NULL state before dropping the final reference, to allow them to clean up. This problem may also be caused by a refcounting bug in the application or some element. If I click "cancel" to dismiss the dialog, then totem plays the video just fine. mediainfo shows the following for the video file in question: General Count: 332 Count of stream of this kind : 1 Kind of stream : General Kind of stream : General Stream identifier: 0 Count of video streams : 1 OtherCount : 3 Video_Format_List: AVC Video_Format_WithHint_List : AVC Codecs Video : AVC Video_Language_List : English Other_Format_List: QuickTime TC / / Other_Format_WithHint_List : QuickTime TC / / Other_Codec_List : QuickTime TC / / Other_Language_List : English / / Complete name: /home/roland/Pictures/GoPro-Hero8/2023/05/09/GH010165.MP4 Folder name : /home/roland/Pictures/GoPro-Hero8/2023/05/09 File name extension : GH010165.MP4 File name: GH010165 File extension : MP4 Format : MPEG-4 Format : MPEG-4 Format/Extensions usually used : braw mov mp4 m4v m4a m4b m4p m4r 3ga 3gpa 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma ismt f4a f4b f4v Commercial name : MPEG-4 Format profile : Base Media / Version 1 Internet media type : video/mp4 Codec ID : mp41 Codec ID : mp41 (mp41) Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html CodecID_Compatible : mp41 File size: 2198334022 File size: 2.05 GiB File size: 2 GiB File size: 2.0 GiB File size: 2.05 GiB File size: 2.047 GiB Duration : 2624622 Duration : 43 min 44 s Duration : 43 min 44 s 622 ms Duration : 43 min 44 s Duration : 00:43:44.622 Duration : 00:02:54;27 Duration : 00:43:44.622 (00:02:54;27) Overall bit rate mode: VBR Overall bit rate mode: Variable Overall bit rate : 6700650 Overall bit rate : 6 701 kb/s Frame rate : 29.970 Frame rate : 29.970 FPS Frame count : 5243 Stream size : 10434366 Stream size : 9.95
[Touch-packages] [Bug 2038834] Re: GPU acceleration via VirGL is broken in qemu
Hello Mate, I see that the debdiff you provided applies to Noble, but this bug is also marked as affecting Mantic. Could you provide an updated debdiff for the Mantic version? Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2038834 Title: GPU acceleration via VirGL is broken in qemu Status in Release Notes for Ubuntu: New Status in mesa package in Ubuntu: Fix Released Status in mesa source package in Mantic: New Status in mesa source package in Noble: Fix Released Bug description: [ Impact ] * Enabling GPU acceleration can cause host-side crashes on mantic/noble VMs * This was reported by someone else upstream and is already fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25580. [ Test Plan ] * I've tested the patch on an affected macOS host running Ubuntu in UTM with OpenGL enabled on both Mantic and Noble VMs. * Anyone else can do the same on an affected host by simply installing the patched package and booting to the desktop. [ Where problems could occur ] * This patch fixes an upstream mesa regression which caused libvirglrendrer to crash on the host side. * This makes a non-working use case work, VirGL on affected hosts cannot regress as it simply didn't work before. * Risk of breakage is mainly from other packages possible affected by a mesa rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/2038834/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
517s === FAILURES === 517s TestApportValgrind.test_valgrind_min_installed 517s 517s self = 517s 517s def test_valgrind_min_installed(self): 517s """Valgrind is installed and recent enough.""" 517s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 517s (ret, out, err) = self._call(cmd) 517s > self.assertEqual(err, "") 517s E AssertionError: "==2567== Invalid write of size 4\n==2567[1064 chars]= \n" != '' 517s E - ==2567== Invalid write of size 4 517s E - ==2567==at 0x4843040: ??? (in /usr/lib/arm-linux-gnueabihf/libselinux.so.1) 517s E - ==2567== Address 0xfec9a7e4 is on thread 1's stack 517s E - ==2567== 64 bytes below stack pointer 517s E - ==2567== 517s E - ==2567== Invalid write of size 4 517s E - ==2567==at 0x4842F96: ??? (in /usr/lib/arm-linux-gnueabihf/libselinux.so.1) 517s E - ==2567== Address 0xfec9a758 is on thread 1's stack 517s E - ==2567== 160 bytes below stack pointer 517s E - ==2567== 517s E - ==2567== Invalid write of size 4 517s E - ==2567==at 0x484958C: selinuxfs_exists (in /usr/lib/arm-linux-gnueabihf/libselinux.so.1) 517s E - ==2567== Address 0xfec9a7bc is on thread 1's stack 517s E - ==2567== 48 bytes below stack pointer 517s E - ==2567== 517s E - ==2567== Invalid write of size 4 517s E - ==2567==at 0x4842F0E: ??? (in /usr/lib/arm-linux-gnueabihf/libselinux.so.1) 517s E - ==2567== Address 0xfec9a690 is on thread 1's stack 517s E - ==2567== 16 bytes below stack pointer 517s E - ==2567== 517s E - ==2567== Invalid write of size 4 517s E - ==2567==at 0x4842E62: ??? (in /usr/lib/arm-linux-gnueabihf/libselinux.so.1) 517s E - ==2567== Address 0xfec9a6a0 is on thread 1's stack 517s E - ==2567== 8 bytes below stack pointer 517s E - ==2567== 517s 517s tests/integration/test_apport_valgrind.py:45: AssertionError 517s === warnings summary === Full log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble- bdrung-ppa/noble/armhf/a/apport/20231116_191750_27834@/log.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2032851] Re: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: new apparmor package pre-installation script subprocess returned error exit status 1
Hello Ravi, or anyone else affected, Accepted apparmor into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu5.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apparmor (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- 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/2032851 Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: new apparmor package pre-installation script subprocess returned error exit status 1 Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Focal: Fix Committed Bug description: [ Impact ] * During an apparmor package upgrade, the cache files were deleted, but there could also be directories under /etc/apparmor.d/cache/ which the pre installation scripts did not account for. The upgrade would then fail with the following error message because it would not be able to remove the directories: package:apparmor:2.12-4ubuntu5.3 Preparing to unpack .../16-apparmor_2.13.3-7ubuntu5.2_amd64.deb ... rm: cannot remove '/etc/apparmor.d/cache/bf9d6da9.0': Is a directory dpkg: error processing archive /tmp/apt-dpkg-install-InP0fz/16-apparmor_2.13.3-7ubuntu5.2_amd64.deb (--unpack): new apparmor package pre-installation script subprocess returned error exit status 1 ErrorMessage: new apparmor package pre-installation script subprocess returned error exit status 1 [ Test Plan ] * On a bionic machine, create a directory under /etc/apparmor.d/cache sudo mkdir /etc/apparmor.d/cache/test * To simulate a system upgrade to focal, you can run the following steps 1. Add the focal archive sudo bash -c "cat
[Touch-packages] [Bug 1841072] Related fix merged to oslo.utils (master)
Reviewed: https://review.opendev.org/c/openstack/oslo.utils/+/850099 Committed: https://opendev.org/openstack/oslo.utils/commit/2319e6d32812ac8244b8dcacee6d1fadfab1c656 Submitter: "Zuul (22348)" Branch:master commit 2319e6d32812ac8244b8dcacee6d1fadfab1c656 Author: Takashi Kajinami Date: Mon Jul 18 22:18:27 2022 +0900 Remove strict from is_same_callback() The strict argument has been deprecated since 4.6.0 because it has no effect in Python >=3.8 [1]. Because now this library supports only Python >=3.8, the logic for old python versions can be removed. [1] https://review.opendev.org/c/openstack/oslo.utils/+/750216 Related-Bug: #1841072 Change-Id: I5873c0df347a4e9a8a1fbfcf9f1212af14f7aef2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1841072 Title: test_reflection.CallbackEqualityTest.test_different_instance_callbacks fails on Python 3.8 Status in oslo.utils: Fix Released Status in python-oslo.utils package in Ubuntu: Fix Released Status in python3-defaults package in Ubuntu: Invalid Bug description: When running the unit test on Python 3.8, it fails with the following traceback: oslo_utils.tests.test_reflection.CallbackEqualityTest.test_different_instance_callbacks --- Captured traceback: ~~~ b'Traceback (most recent call last):' b' File "/tmp/oslo.utils/oslo_utils/tests/test_reflection.py", line 156, in test_different_instance_callbacks' b'self.assertTrue(reflection.is_same_callback(b.b, c.b, strict=False))' b' File "/tmp/oslo.utils/.tox/py38/lib/python3.8/site-packages/unittest2/case.py", line 702, in assertTrue' b'raise self.failureException(msg)' b'AssertionError: False is not true' b'' This is apparently caused by a behavior change in Python 3.8 due to [1]. I have confirmed the different behavior by running tests manually on 3.6, 3.7 (both return True) and 3.8. According to [2], only taskflow seems to be using that method now, and it is not changing the default value for the "strict" parameter. [1] - https://bugs.python.org/issue1617161 [2] - http://codesearch.openstack.org/?q=is_same_callback=nope== To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.utils/+bug/1841072/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
test/apport-valgrind: do not limit diff size: https://github.com/canonical/apport/pull/253 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
I need to set maxDiff to None to see the full output of valgrind. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2043326] Re: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück
*** This bug is a duplicate of bug 2032851 *** https://bugs.launchpad.net/bugs/2032851 Hello! Thanks for the report. I noticed that it is a duplicate of Bug 2032851 which already has a fix on its way. Meanwhile, as a workaround, you could fix the upgrade issue by running rm -r /etc/apparmor.d/cache/87595f25.0 /etc/apparmor.d/cache/bf9d6da9.0 /etc/apparmor.d/cache/e10c1cf9.0 and try apt --fix-broken install again Thanks. -- 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/2043326 Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück Status in apparmor package in Ubuntu: Confirmed Bug description: Nach dem upgrade auf 20.04 kann ich nicht mehr die libre office dateien öffnen.Die Fehlermeldung war "BrokenCount>0" Ich habe alle möglichen >apt-get> Befehle probiert ohne Erfolg. Kann man das letzte upgrade rückgängig machen und neu aktualisieren? 1. erste Installierung von ubuntu mittels der linux DVD von Computerwissen. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: apparmor 2.12-4ubuntu5.3 ProcVersionSignature: Ubuntu 5.4.0-166.183-generic 5.4.252 Uname: Linux 5.4.0-166-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 AptOrdering: apparmor:amd64: Install libreoffice-common:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Nov 12 17:39:51 2023 ErrorMessage: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück InstallationDate: Installed on 2023-05-31 (165 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-166-generic root=UUID=66ff54a3-a945-458b-9c63-7675499cd872 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: apparmor Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: Upgraded to focal on 2023-11-02 (10 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2043326/+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 2043326] Re: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück
*** This bug is a duplicate of bug 2032851 *** https://bugs.launchpad.net/bugs/2032851 ** This bug has been marked a duplicate of bug 2032851 package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: new apparmor package pre-installation script subprocess returned error exit status 1 -- 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/2043326 Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück Status in apparmor package in Ubuntu: Confirmed Bug description: Nach dem upgrade auf 20.04 kann ich nicht mehr die libre office dateien öffnen.Die Fehlermeldung war "BrokenCount>0" Ich habe alle möglichen >apt-get> Befehle probiert ohne Erfolg. Kann man das letzte upgrade rückgängig machen und neu aktualisieren? 1. erste Installierung von ubuntu mittels der linux DVD von Computerwissen. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: apparmor 2.12-4ubuntu5.3 ProcVersionSignature: Ubuntu 5.4.0-166.183-generic 5.4.252 Uname: Linux 5.4.0-166-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 AptOrdering: apparmor:amd64: Install libreoffice-common:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Nov 12 17:39:51 2023 ErrorMessage: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück InstallationDate: Installed on 2023-05-31 (165 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-166-generic root=UUID=66ff54a3-a945-458b-9c63-7675499cd872 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: apparmor Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: Upgraded to focal on 2023-11-02 (10 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2043326/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
** Tags added: rls-nn-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi, Just wanted to check back to see if the reproducer and fix worked in your testing environments. I was also curious if it were possible to share any plans around when an update that contains this fix might be released. Thanks again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs Status in cloud-images: New Status in e2fsprogs package in Ubuntu: In Progress Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: In Progress Status in e2fsprogs source package in Jammy: In Progress Status in e2fsprogs source package in Lunar: In Progress Status in e2fsprogs source package in Mantic: In Progress Bug description: [Impact] This is a long running bug plaguing cloud-images, where on a rare occasion resize2fs would fail and the image would not resize to fit the entire disk. Online resizes would fail due to a superblock checksum mismatch, where the superblock in memory differs from what is currently on disk due to changes made to the image. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. Changing the read of the superblock to Direct I/O solves the issue. [Testcase] Start an c5.large instance on AWS, and attach a 60gb gp3 volume for use as a scratch disk. Run the following script, courtesy of Krister Johansen and his team: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] We are changing how resize2fs reads the superblock from underlying disks. If a regression were to occur, resize2fs could fail to resize offline or online volumes. As all cloud-images are online resized during their initial boot, this could have a large impact to public and private clouds should a regression occur. [Other info] Upstream mailing list discussion: https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/ https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This was fixed in the below commit upstream: commit 43a498e938887956f393b5e45ea6ac79cc5f4b84 Author: Theodore Ts'o Date: Thu, 15 Jun 2023 00:17:01 -0400 Subject: resize2fs: use Direct I/O when reading the superblock for online resizes Link: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 The commit has not been tagged to any release. All supported Ubuntu releases require this fix, and need to be published in standard non- ESM archives to be picked up in cloud images. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+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 2041830] Re: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset
** Changed in: gdb (Ubuntu) Assignee: (unassigned) => Mate Kukri (mkukri) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2041830 Title: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset Status in gdb package in Ubuntu: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gdb. This problem was most recently seen with package version 14.0.50.20230907-0ubuntu1, the problem page at https://errors.ubuntu.com/problem/e052ff0ad61743594bf64a85ca1e18b6e353025d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041830/+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 2041830] Re: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset
** Tags removed: rls-mm-incoming ** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2041830 Title: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset Status in gdb package in Ubuntu: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gdb. This problem was most recently seen with package version 14.0.50.20230907-0ubuntu1, the problem page at https://errors.ubuntu.com/problem/e052ff0ad61743594bf64a85ca1e18b6e353025d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041830/+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 2041830] Re: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset
Looking at the crash reports (e.g. https://errors.ubuntu.com/oops/cac73123-849b-11ee-9b95-fa163ec44ecd) the ProcCmdline look similar: /usr/bin/gdb --ex file\ "/opt/teamviewer/tv_bin/TeamViewer" --ex core- file\ /tmp/apport_core_b5i0g31o --batch --ex set\ backtrace\ limit\ 2000 -iex set\ debuginfod\ enable\ off --ex p\ -99 --ex info\ registers --ex p\ -99 --ex x/16i\ $pc --ex p\ -99 --ex bt\ full --ex p\ -99 --ex thread\ apply\ all\ bt\ full --ex p\ -99 --ex print\ __abort_msg->msg --ex p\ -99 --ex print\ __glib_assert_msg --ex p\ -99 --ex print\ (char*)\ __nih_abort_msg --ex p\ -99 So we could try to reproduce crashing with running gdb on TeamViewer. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2041830 Title: /usr/bin/gdb:6:dump_core:internal_vproblem:internal_verror:internal_error_loc:objfile::text_section_offset Status in gdb package in Ubuntu: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gdb. This problem was most recently seen with package version 14.0.50.20230907-0ubuntu1, the problem page at https://errors.ubuntu.com/problem/e052ff0ad61743594bf64a85ca1e18b6e353025d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041830/+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 2043713] [NEW] armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
Public bug reported: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf ** Affects: apport (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2042710] Re: Can't enter cryptsetup password on MacBook Pro 2017 (MacBookPro14, 1) due to missing kernel modules in initramfs
** Tags removed: foundations-todo ** Changed in: initramfs-tools (Ubuntu) Assignee: Benjamin Drung (bdrung) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2042710 Title: Can't enter cryptsetup password on MacBook Pro 2017 (MacBookPro14,1) due to missing kernel modules in initramfs Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Mantic: New Bug description: [ Impact ] I have a MacBook Pro 2017 (MacBookPro14,1) with an encrypted root partition, which I decrypt via passphrase during boot, at the "Please unlock disk nvme0n1p4_crypt" prompt. Using 23.04 "Lunar" this worked fine. However after upgrading to 23.10 "Mantic", the built-in keyboard doesn't work for entering the passphrase. Quickest workaround: plug in a USB keyboard for entering the passphrase. Workaround: add the following modules to "/etc/initramfs- tools/modules": spi_pxa2xx_platform intel_lpss_pci ... then "sudo update-initramfs -u". I found that both kernel modules were required to get the keyboard recognised in initramfs. [ Test Plan ] The -generic kernel and probably all kernel flavors contain the SPI and PCI driver (on amd64). On mantic systems, you can verify the current initrd doesn't contain these modules by decompressing the initramfs and listing its files: $ lsinitramfs /boot/initrd.img-6.5.0-10-generic | grep 'spi-pxa2xx-platform\|intel-lpss-pci' After installing the updated initramfs-tools package, your current initramfs should be automatically rebuilt and pick up the kernel modules: $ lsinitramfs /boot/initrd.img-6.5.0-10-generic | grep 'spi-pxa2xx-platform\|intel-lpss-pci' usr/lib/modules/6.5.0-10-generic/kernel/drivers/mfd/intel-lpss-pci.ko.zst usr/lib/modules/6.5.0-10-generic/kernel/drivers/spi/spi-pxa2xx-platform.ko.zst Test case on MacBook Pro 2017 laptops: Remove all previous workarounds. Install the fixed initramfs-tools version. Then the keyboard should work during boot to enter the passphrase. [ Where problems could occur ] This is making the initramfs slightly bigger. In my testing, both added were 23,852 bytes in total (or 0.02 % on a 102 MB initramfs). [ Remaining original report ] I did a bit of digging into what changed for 23.10. It could potentially (?) be commit 2df78bbb143884b9601a32608e12e43d40ccb0b0 "Do not install ARM/RISCV specific modules on other architectures". I had a look into how dracut handles it. Turns out that they specifically include "spi_pxa2xx_platform" after reporting a similar bug report in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2166209 I don't know how (if?) they handle the 2nd module, "intel_lpss_pci". Anyway, I don't need an immediate fix since the workaround works for me. Just posting this for further investigation, and for any other MacBook Pro users in the same situation. Thanks for working on Ubuntu, I think you're all amazing! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2042710/+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 2043326] Re: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: apparmor (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2043326 Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück Status in apparmor package in Ubuntu: Confirmed Bug description: Nach dem upgrade auf 20.04 kann ich nicht mehr die libre office dateien öffnen.Die Fehlermeldung war "BrokenCount>0" Ich habe alle möglichen >apt-get> Befehle probiert ohne Erfolg. Kann man das letzte upgrade rückgängig machen und neu aktualisieren? 1. erste Installierung von ubuntu mittels der linux DVD von Computerwissen. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: apparmor 2.12-4ubuntu5.3 ProcVersionSignature: Ubuntu 5.4.0-166.183-generic 5.4.252 Uname: Linux 5.4.0-166-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 AptOrdering: apparmor:amd64: Install libreoffice-common:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Nov 12 17:39:51 2023 ErrorMessage: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück InstallationDate: Installed on 2023-05-31 (165 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-166-generic root=UUID=66ff54a3-a945-458b-9c63-7675499cd872 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: apparmor Title: package apparmor 2.12-4ubuntu5.3 failed to install/upgrade: »neues apparmor-Skript des Paketes pre-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: Upgraded to focal on 2023-11-02 (10 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2043326/+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 1969365] Re: focal: backport kexec fallback patch
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455719 -- 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/1969365 Title: focal: backport kexec fallback patch Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Triaged Bug description: It would be great if focal's systemd could have https://github.com/systemd/systemd/commit/71180f8e57f8fbb55978b00a13990c79093ff7b3 backported to it. [Impact] We have observed that kexec'ing to another kernel will fail as the drive containing the `kexec` binary has been unmounted by the time systemd attempts to do so, indicated in the console: Starting Reboot via kexec... [ 163.960938] shutdown[1]: (sd-kexec) failed with exit status 1. [ 163.963463] reboot: Restarting system [Test Plan] 1) Launch a 20.04 instance 2) `apt-get install kexec-tools` 3) In `/boot`, filling in whatever needed in your environment: kexec -l vmlinuz --initrd initrd.img --append '' 4) `reboot` (I have reproduced this in a single-disk VM, so I assume it reproduces ~everywhere: if not, `apt-get remove kexec-tools` before the `reboot` could be used to emulate the unmounting.) [Where problems could occur] Users could inadvertently be relying on the current behaviour: if they have configured their systems to kexec, they currently will be rebooting normally, and this patch would cause them to start actually kexec'ing. [Other info] We're currently maintaining a systemd tree with only this patch added to focal's tree: this patch has received a bunch of testing from us in focal. This patch landed in v246, so it's already present in supported releases later than focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1969365/+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 1837227] Re: systemd mount units fail during boot, while file system is correctly mounted
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455719 -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in systemd source package in Bionic: Won't Fix Status in linux source package in Focal: Fix Released Status in systemd source package in Focal: In Progress Status in linux source package in Jammy: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergency mode [Test Plan] This issue seems to happen randomly, and doesn't seem related to a specific mount unit. We've used a test script with good results during investigation to reproduce similar mount failures in a running system, and have seen a strong correlation between the script failures and the boot time mount failures. The attached 'rep-tmpfs.sh' script should be used to validate that mount points are working correctly under stress. One can run through the different variants as below: # ./rep-tmpfs.sh --variant-0 # ./rep-tmpfs.sh --variant-1 # ./rep-tmpfs.sh --variant-2 # ./rep-tmpfs.sh --variant-3 # ./rep-tmpfs.sh --variant-4 All of these should run successfully without any reported errors. [Where problems could occur] The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. [Other Info] This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo For Bionic, systemd requires several dependency patches as below: 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" Additionally, the kernel also requires the following patches: 28ca0d6d39ab list: introduce list_for_each_continue() 9f6c61f96f2d proc/mounts: add cursor [Original Description] In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+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 2037281] Re: Shutdown when triggering daemon-reload eary in boot
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455718 ** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455719 -- 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/2037281 Title: Shutdown when triggering daemon-reload eary in boot Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in systemd source package in Jammy: New Bug description: In Ubuntu Core 20, and Ubuntu Core 22, we are encountering an issue where if a service, started earlier than devices are processed by udev, does `systemctl daemon-reload`, the system shuts down. This is due to devices for mounted filesystem temporarily taken dead, which pulls most units down. This was fixed by upstream in https://github.com/systemd/systemd/pull/23218. But this was not backported to the versions used by Ubuntu packages for focal and jammy. The needed commit from that PR is the one with message `core/device: ignore DEVICE_FOUND_UDEV bit on switching root`. This patch applies to 245.4-4ubuntu3.22 (focal) without rebasing needed. And I suppose it does also for jammy. I have manually tested the fix with Ubuntu Core 20, and this fixes our issue. We would like this patch to be backported to focal-updates and jammy- updates. Thank you in advance. [ Impact ] If a user adds a service that calls `systemctl daemon-reload`, and if this service is started before systemd-udevd. And if the initrd is systemd (the case of Ubuntu Core), then most service will be stopped or cancel, and the machine will mostly shutdown everything and hang. The fix has been backported down to 250 upstream. It is already on kinetic and later. The fix only affects systems where systemd is used in initrd. [ Test Plan ] On Ubuntu Core 20 (with Core 22 kernel) or on Ubuntu Core 22. Or on any system that uses systemd in initrd. Add a systemd service that calls `systemctl daemon-reload`. The service should have `DefaultDependencies=no` in order to start as soon as possible and be enabled. Restart the machine. If fix is not applied, after the service is started, most of units with be shutdown, and the system will be unusable. [ Where problems could occur ] This should affect systems with systemd in initrd. There are risks on systems that have an udev rule in initrd not present in the main system. There are risks on systems that use db_persist in initrd where the device can potentially get dead state. Though this does not seem to happen on Ubuntu Core 22, even though we use db_persist for dev mapper devices. Regression is upstream bug #23429. Commits named "core/device: device_coldplug(): don't set DEVICE_DEAD" and "core/device: do not downgrade device state if it is already enumerated" could be applied as well. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037281/+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 2024009] Re: [PATCH] systemd-resolved can't follow more than 8 CNAMEs
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455719 -- 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/2024009 Title: [PATCH] systemd-resolved can't follow more than 8 CNAMEs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Triaged Bug description: [Impact] Using systemd-resolved to resolve a hostname which has more than 8 CNAME redirects will fail because of the hard-coded limit. While this case is somewhat rare, the original reporter demonstrated a real-world scenario where this happened (although that particular hostname seems to be fixed now). [Test Plan] This test plan uses a LXC container to test systemd-resolved on Focal. If LXD has not been configured on your system, start with: $ lxd init --auto Then, create a Focal container with: $ lxc launch ubuntu-daily:focal focal Install dnsmasq-base if needed: $ apt install dnsmasq-base Stop other DNS servers: $ systemctl stop systemd-resolved $ kill -9 $(pgrep dnsmasq) Now, on the host start a new DNS server that listens on lxdbr0, and sets up an A record, and many CNAME records which ultimately redirect to the A record: $ dnsmasq \ --cname=test10.lan,test9.lan \ --cname=test9.lan,test8.lan \ --cname=test8.lan,test7.lan \ --cname=test7.lan,test6.lan \ --cname=test6.lan,test5.lan \ --cname=test5.lan,test4.lan \ --cname=test4.lan,test3.lan \ --cname=test3.lan,test2.lan \ --cname=test2.lan,test1.lan \ --cname=test1.lan,test0.lan \ -k -i lxdbr0 -z -I lo --host-record=test0.lan,$IP where $IP is any host on your network. Now, obtain a shell in the Focal container: $ lxc exec focal bash Attempt to resolve test10.lan: $ resolvectl query test10.lan test10.lan: resolve call failed: CNAME loop detected, or CNAME resolving disabled on 'test2.lan' On an affected system, the above error will be seen. On a patched system, the hostname should be resolved. [Where problems could occur] The patch simply increases the maximum CNAME redirects that are allowed from 8 to 16, so a reasonable limit is still imposed. If an application specifically relied on systemd-resolved's limit being at 8, then that application would potentially see new behavior. [Original Description] On Ubuntu 20.04 (systemd v245.4-4ubuntu3.21), hostname resolution only follows 8 CNAME redirections maximum. So when using a service like Azure Virtual Desktop that has between 9 and 12 redirections, name resolution fails. $ host client.wvd.microsoft.com Host client.wvd.microsoft.com not found: 2(SERVFAIL) $ resolvectl query client.wvd.microsoft.com client.wvd.microsoft.com: resolve call failed: CNAME loop detected, or CNAME resolving disabled on 'waws-prod-zrh-ff7172dd.sip.p.azurewebsites.windows.net' On the other hand it's working fine on Ubuntu 20.04 because CNAME loop limit has been raised from 8 to 16. $ host client.wvd.microsoft.com client.wvd.microsoft.com is an alias for client.privatelink-global.wvd.microsoft.com. client.privatelink-global.wvd.microsoft.com is an alias for client.privatelink.wvd.microsoft.com. client.privatelink.wvd.microsoft.com is an alias for rdweb.wvd.microsoft.com. rdweb.wvd.microsoft.com is an alias for rdweb.privatelink-global.wvd.microsoft.com. rdweb.privatelink-global.wvd.microsoft.com is an alias for rdweb.privatelink.wvd.microsoft.com. rdweb.privatelink.wvd.microsoft.com is an alias for rdweb-prod-geo.trafficmanager.net. rdweb-prod-geo.trafficmanager.net is an alias for mrs-chnor1c101-rdweb-prod.wvd-ase-chnor1c101-prod.p.azurewebsites.net. mrs-chnor1c101-rdweb-prod.wvd-ase-chnor1c101-prod.p.azurewebsites.net is an alias for waws-prod-zrh-63daa049.sip.p.azurewebsites.windows.net. waws-prod-zrh-63daa049.sip.p.azurewebsites.windows.net is an alias for waws-prod-zrh-63daa049.cloudapp.net. waws-prod-zrh-63daa049.cloudapp.net has address 51.107.69.35 Here's a quick fix that raises the max CNAME limit from 8 to 16 like it is in Ubuntu 22.04, it fixes the problem for me. Best regards, Vincent. --- systemd-245.4.ORIG/src/resolve/resolved-dns-query.c 2023-06-15 16:58:25.454156663 +0200 +++ systemd-245.4/src/resolve/resolved-dns-query.c2023-06-01 14:30:09.0 +0200 @@ -10,7 +10,7 @@ #include "resolved-etc-hosts.h" #include "string-util.h" -#define CNAME_MAX 8 +#define CNAME_MAX 16 #define QUERIES_MAX 2048 #define AUXILIARY_QUERIES_MAX 64 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd 249.11-0ubuntu3.9 [modified: usr/lib/sysctl.d/50-default.conf] ProcVersionSignature: Ubuntu 5.19.0-42.43~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-42-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion:
[Touch-packages] [Bug 2029352] Re: systemd/ 245.4-4ubuntu3.22 ADT test failure with linux/5.4.0-156.173
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455719 -- 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/2029352 Title: systemd/ 245.4-4ubuntu3.22 ADT test failure with linux/5.4.0-156.173 Status in systemd package in Ubuntu: Invalid Status in systemd source package in Focal: Confirmed Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.4.0-156.173 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. root-unittests fails. Testing failed on: armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/s/systemd/20230727_150132_9cd77@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2029352/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable
** Merge proposal linked: https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/455718 -- 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/2035122 Title: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: [Impact] When working with ubuntu core or ubuntu core desktop, neither */etc/default/locale* nor */etc/default/keyboard* are modifiable, so it's not possible to set the global keyboard or the global language. This is required to allow to set the GDM language, and the default one during installation. The first half of the solution is to create the folder */etc/writable/default*, and make soft-links from */etc/default/locale* to */etc/writable/default/locale* and from */etc/default/keyboard* to */etc/writable/default/keyboard*, just like it is already being done with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and , */etc/timezone*. This solution, unfortunately, isn't complete. Although any application that just reads the files will work, not all of the applications that write to them will; specifically the systemd utilities that set the contents for those files, because they don't open the file directly; instead, they create first the new file in the same folder than the old one, fill its contents, and only then delete the old one and rename the new one. To solve this, systemd in Ubuntu already has several patches that detect if a file is a soft-link, in which case it replaces the old path with the destination one. Currently I have in place a patch for Ubuntu Core Desktop that implements both changes for both */etc/default/locale* and */etc/default/keyboard*. [Test plan] Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale to the specified one. Also, *localectl* should return the current locale. [Where problems could occur] In general, applications just read the content of the file and use the DBus interface to set the locale, so only those applications that modify by themselves the */etc/default/keyboard* and/or */etc/default/locale* would present a problem, in which case they would require specific patches. Anyway, those applications neither would work with the current state (with those files in a read-only filesystem). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2038834] Re: GPU acceleration via VirGL is broken in qemu
** Changed in: mesa (Ubuntu Noble) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2038834 Title: GPU acceleration via VirGL is broken in qemu Status in Release Notes for Ubuntu: New Status in mesa package in Ubuntu: Fix Released Status in mesa source package in Mantic: New Status in mesa source package in Noble: Fix Released Bug description: [ Impact ] * Enabling GPU acceleration can cause host-side crashes on mantic/noble VMs * This was reported by someone else upstream and is already fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25580. [ Test Plan ] * I've tested the patch on an affected macOS host running Ubuntu in UTM with OpenGL enabled on both Mantic and Noble VMs. * Anyone else can do the same on an affected host by simply installing the patched package and booting to the desktop. [ Where problems could occur ] * This patch fixes an upstream mesa regression which caused libvirglrendrer to crash on the host side. * This makes a non-working use case work, VirGL on affected hosts cannot regress as it simply didn't work before. * Risk of breakage is mainly from other packages possible affected by a mesa rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/2038834/+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 1951586] Re: Need option to specify wifi regulatory domain
Setting network-manager back to confirmed as I think the case is made that this is an issue, despite upstream having reservations about whether network-manager is quite the right place for this particular setting. Also setting netplan.io in jammy to fix released as 0.105 was back-ported there quite a while ago now and the current (22.04.3) image should support setting this at first-boot. Setting kinetic to won't fix (as it's EOL). ** Changed in: network-manager (Ubuntu Kinetic) Status: Incomplete => Won't Fix ** Changed in: network-manager (Ubuntu Jammy) Status: Incomplete => Confirmed ** Changed in: network-manager (Ubuntu) Status: Incomplete => Confirmed ** Changed in: netplan.io (Ubuntu Jammy) Status: Triaged => Fix Released ** Changed in: netplan Assignee: Lukas Märdian (slyon) => (unassigned) ** Also affects: network-manager (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Noble) Importance: Low Status: Confirmed ** Also affects: netplan.io (Ubuntu Noble) Importance: Medium Status: Fix Released ** Also affects: network-manager (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: netplan.io (Ubuntu Lunar) Status: New => Fix Released ** Changed in: netplan.io (Ubuntu Mantic) Status: New => Fix Released ** Changed in: network-manager (Ubuntu Lunar) Importance: Undecided => Low ** Changed in: network-manager (Ubuntu Lunar) Status: New => Confirmed ** Changed in: network-manager (Ubuntu Mantic) Importance: Undecided => Low ** Changed in: network-manager (Ubuntu Mantic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1951586 Title: Need option to specify wifi regulatory domain Status in cloud-init: Invalid Status in netplan: Fix Released Status in NetworkManager: New Status in netplan.io package in Ubuntu: Fix Released Status in network-manager package in Ubuntu: Confirmed Status in netplan.io source package in Jammy: Fix Released Status in network-manager source package in Jammy: Confirmed Status in netplan.io source package in Kinetic: Fix Released Status in network-manager source package in Kinetic: Won't Fix Status in netplan.io source package in Lunar: Fix Released Status in network-manager source package in Lunar: Confirmed Status in netplan.io source package in Mantic: Fix Released Status in network-manager source package in Mantic: Confirmed Status in netplan.io source package in Noble: Fix Released Status in network-manager source package in Noble: Confirmed Bug description: It would be nice if netplan offered an option to specify the wifi regulatory domain (country code). For devices such as the Raspberry Pi you are currently advertising that users can simply setup Ubuntu Server headless by putting the wifi configuration details in cloudinit/netplan's "network-config" on the FAT partition of the SD card: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#3-wifi-or-ethernet But an option to set the wifi country code there does not seem to exist, so may not work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1951586/+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 1432599]
When an interface is configured outside of NetworkManager's knowledge (like libvirt's or docker's bridge), then NetworkManager generates an in-memory connection profile and pretends(!) that this is active. This is to show that something is going on with the device, and NetworkManager is supposed to touch that device. Whether this pretend mode is of any use is a good question. It's obviously confusing. I actually do make use of this behaviour to have a dispatcher script that does something for such external devices, so it's not entirely useless. Also, it causes the output of `nmcli device` to show that *something* is going on there. Although, maybe that's more confusing than helpful. In any case, NetworkManager needs a way to express that something is happening with this devices, and this is the way it does that. It doesn't mean that NetworkManager actually touches the device. Comment 26 does not say what actual problem NetworkManager causes by this (aside the confusion to the user). Comment 26 also explains that `nm-online` gives wrong results. I think nm-online has one real use-case: to implement `NetworkManager-wait-online.service` (with the `--startup` option). Without the `--startup` option, I don't think it's of any use at all. It can only return "online" or "offline". It maps the NetworkManager's states "local", "site", and "global" to "online". I think that is is sensible, if you connect to a libvirt bridge some network is configured and nm-online considers that as "online". However I don't think that describing the online state in two words is meaningful and calling `nm-online` is not useful. For a while NetworkManager had a udev rule to automatically unmanage docker bridges. But that was dropped, because docker bridges are nothing special. It's a common thing that something aside NetworkManager configures an interface and NetworkManager must not interfere. So, what actual problems are causes by this? --- > 1) You should never need to create (actually *shouldn't* create) an ifcfg-* > file for a libvirt-created bridge. If proper operation requires this, then > there is definitely a bug. Right. NM doesn't. > 2) NetworkManager should never mess around with bridge devices created by other entities (e.g. libvirt, but really anyone else), and no special plugin should be required to make that happen. If we (libvirt) wanted NM to manage the bridge, we would create it via NM. Right. NM shouldn't. Does it? -- 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/1432599 Title: Network-manager tries to manage virbr0, which it should not Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Fedora: Won't Fix Bug description: Since a recent upgrade in vivid, nm is trying to manage virbr0. This results in my main machine not getting a real IP address on eth0, and virtual machines not being able to use the network. This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1166199 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 16 12:36:07 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-12-13 (92 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) IpRoute: default via 10.0.0.1 dev eth0 proto static metric 1024 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.75 192.168.111.0/24 dev wlan0 proto kernel scope link src 192.168.111.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) http_proxy: http://localhost:8118/ nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. no_proxy: localhost,127.0.0.0/8,::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+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 1432599]
In previous versions of GNOME (such as the version in RHEL 7.6), an active NetworkManager connection profile for virbr0 caused a wired Ethernet connection to appear in the top bar in GNOME Shell. It seems this is actually now suppressed, and GNOME Control Center does not expose the virbr0 device on the network panel (or allow it to be configured there). For users who are looking to check if a NetworkManager connection profile is active excluding libvirt's, disabling NetworkManager's control of the bridge devices still seems to me like an appropriate method to adjust the behavior of nm-online. I'm not sure I agree with the comment about *never* using ifcfg: the configuration I provided above is equivalent to setting "unmanaged-devices=interface-name:virbr0" in /etc/NetworkManager/NetworkManager.conf. It is read by NetworkManager's ifcfg-rh settings plugin, versus NetworkManager's keyfile settings plugin. It's also worth mentioning that libvirt allows hook scripts to be run when a virtual network switch is started/stopped, which can substitute for NetworkManager dispatcher scripts for these devices: https://libvirt.org/hooks.html -- 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/1432599 Title: Network-manager tries to manage virbr0, which it should not Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Fedora: Won't Fix Bug description: Since a recent upgrade in vivid, nm is trying to manage virbr0. This results in my main machine not getting a real IP address on eth0, and virtual machines not being able to use the network. This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1166199 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 16 12:36:07 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-12-13 (92 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) IpRoute: default via 10.0.0.1 dev eth0 proto static metric 1024 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.75 192.168.111.0/24 dev wlan0 proto kernel scope link src 192.168.111.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) http_proxy: http://localhost:8118/ nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. no_proxy: localhost,127.0.0.0/8,::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+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 1432599]
This has remained reproducible in every release from Fedora 23 through Fedora 30 -- the problem never went away (and the underlying reason/behavior never changed). Please re-open against Fedora 30. This occurs in Fedora Workstation when it is installed to disk. The behavior can be very easily seen by booting the Fedora Workstation live image, without any wired or wireless network connections. (However the missing 'libvirt-daemon-config-network' package needs to be installed from local storage after boot, except on Fedora 23 and Fedora 26 where this is already present.) [liveuser@localhost ~]$ nmcli connection NAMEUUID TYPEDEVICE virbr0 f20e2384-0dca-4a6b-b4cb-3dd1582c1ce1 bridge virbr0 [liveuser@localhost ~]$ nm-online Connecting... 30s [online] This is (falsely) indicating that "the network is connected", as described in nm-online(1). Configuring NetworkManager to not manage virbr0 still works around this: [liveuser@localhost ~]$ cat > ifcfg-virbr0 << EOF > DEVICE=virbr0 > NM_CONTROLLED=no > EOF [liveuser@localhost ~]$ sudo cp ifcfg-virbr0 /etc/sysconfig/network-scripts/ [liveuser@localhost ~]$ rm ifcfg-virbr0 [liveuser@localhost ~]$ sudo nmcli connection reload [liveuser@localhost ~]$ nmcli connection [liveuser@localhost ~]$ nm-online Connecting...0s [offline] But this should be an automatic setting, not a manual one. We already know that the explicit configuration of this interface is handled by libvirt (see /etc/libvirt/qemu/networks/default.xml), and NetworkManager should not be managing it and potentially changing its state. However this more generally applies to any virtual network switch created with libvirt though, whether or not it is named virbr0. Which package should contain the hooks to do this? Should NetworkManager be able to identify a libvirt network switch, or should libvirt configure NetworkManager (perhaps using a separate settings plugin) to not manage its devices? -- 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/1432599 Title: Network-manager tries to manage virbr0, which it should not Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Fedora: Won't Fix Bug description: Since a recent upgrade in vivid, nm is trying to manage virbr0. This results in my main machine not getting a real IP address on eth0, and virtual machines not being able to use the network. This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1166199 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 16 12:36:07 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-12-13 (92 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) IpRoute: default via 10.0.0.1 dev eth0 proto static metric 1024 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.75 192.168.111.0/24 dev wlan0 proto kernel scope link src 192.168.111.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) http_proxy: http://localhost:8118/ nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. no_proxy: localhost,127.0.0.0/8,::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+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 1432599]
(NB: I'm a libvirt developer, so I'm writing this comment from that POV) 1) You should never need to create (actually *shouldn't* create) an ifcfg-* file for a libvirt-created bridge. If proper operation requires this, then there is definitely a bug. 2) NetworkManager should never mess around with bridge devices created by other entities (e.g. libvirt, but really anyone else), and no special plugin should be required to make that happen. If we (libvirt) wanted NM to manage the bridge, we would create it via NM. People normally don't see the issue you describe, because almost everybody has a permanently online internet connection these days, but I can see why it would be problematic. Since this behavior has been present in NM for such a long time, I would say that the proper place for the bug to be filed would be upstream rather than in Fedora. I don't know if the NM developers pay more attention to their mailing list, or to their issue tracker on gitlab.freedesktop.org. -- 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/1432599 Title: Network-manager tries to manage virbr0, which it should not Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Fedora: Won't Fix Bug description: Since a recent upgrade in vivid, nm is trying to manage virbr0. This results in my main machine not getting a real IP address on eth0, and virtual machines not being able to use the network. This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1166199 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 16 12:36:07 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-12-13 (92 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) IpRoute: default via 10.0.0.1 dev eth0 proto static metric 1024 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.75 192.168.111.0/24 dev wlan0 proto kernel scope link src 192.168.111.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) http_proxy: http://localhost:8118/ nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. no_proxy: localhost,127.0.0.0/8,::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+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 2043114] Re: sshd segmentation fault on 20.04.6 (focal)
We’re seeing it happen on both bare metal and virtual machines. The VMs are libvirt/QEMU/KVM managed by OpenNebula. The hypervisor is running AlmaLinux 8 with the 4.18.0-477.15.1.el8_8.x86_64 kernel. The VMs have 2 physical/8 vCPUs allocated to them. The VM I used for the reproduction has 2GB of RAM. The VMs where we saw the problem initially have 22GB, but the setup there is a bit more complicated - there are various cgroup v1 limits, such as 2.5GB for system.slice, and 2GB for user slice. However none of that is necessary to reproduce the issue. Since the initial report, we've done a lot of test runs with INFO-level logging on 20.04, 18.04, 22.04, as well as RedHat-family distributions, and we haven’t seen the issue again. Could be some memory corruption bug that is present only on 20.04, I guess. So far I’ve been unable to reproduce it on a 22.04 VM with DEBUG logging on. Thanks. -- 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/2043114 Title: sshd segmentation fault on 20.04.6 (focal) Status in openssh package in Ubuntu: Confirmed Bug description: We have a physical server running Ubuntu 20.04.6 LTS (amd64) and openssh-server 1:8.2p1-4ubuntu0.9. Sometimes sshd crashes with a segmentation fault on remote login with key authentication: [193107.651745] sshd[1229630]: segfault at 5557eba6a008 ip 7f2326a2ca53 sp 7ffcba40c510 error 4 in libc-2.31.so[7f23269b8000+178000] We’ve changed only the following values in the stock sshd_config file: LogLevel DEBUG PasswordAuthentication no MaxStartups 100:30:100 The server is used for automated software testing, and sometimes our test suite might make a large amount of SSH connections in a short period of time, which seems to be correlated with the crashes. But at the same time, I have to note that the connection count was not near the MaxStartups limit, and we’ve had crashes before adding that setting. Since the backtrace shows the debug logging function in the stack, we’re currently experimenting with using `LogLevel INFO` to try and isolate the issue. I am attaching the backtrace. I could provide the full dump file, although I am hesitant due to the possibility of private keys or other sensitive information leaking. # apt-cache policy openssh-server openssh-server: Installed: 1:8.2p1-4ubuntu0.9 Candidate: 1:8.2p1-4ubuntu0.9 Version table: *** 1:8.2p1-4ubuntu0.9 500 500 http://mirrors.storpool.com/ubuntu/archive focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 1:8.2p1-4 500 500 http://mirrors.storpool.com/ubuntu/archive focal/main amd64 Packages --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.27 Architecture: amd64 CasperMD5CheckResult: skip DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.2p1-4ubuntu0.9 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.4.0-128.144-generic 5.4.210 Tags: focal Uname: Linux 5.4.0-128-generic x86_64 UpgradeStatus: Upgraded to focal on 2021-01-13 (1030 days ago) UserGroups: N/A _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2043114/+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
