[Touch-packages] [Bug 1840375] Autopkgtest regression report (shadow/1:4.5-1.1ubuntu2.1)
All autopkgtests for the newly accepted shadow (1:4.5-1.1ubuntu2.1) for disco
have finished running.
The following regressions have been reported in tests triggered by the package:
ubiquity/unknown (armhf)
mariadb-10.3/unknown (armhf)
lxc/3.0.3-0ubuntu1 (s390x)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#shadow
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
New
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Xenial:
Fix Committed
Status in shadow source package in Bionic:
Fix Committed
Status in shadow source package in Disco:
Fix Committed
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
1. install the libnss-extrausers and configure it
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1840375] Autopkgtest regression report (shadow/1:4.5-1ubuntu2.1)
All autopkgtests for the newly accepted shadow (1:4.5-1ubuntu2.1) for bionic
have finished running.
The following regressions have been reported in tests triggered by the package:
buildbot/unknown (armhf)
lxc/unknown (armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#shadow
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
New
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Xenial:
Fix Committed
Status in shadow source package in Bionic:
Fix Committed
Status in shadow source package in Disco:
Fix Committed
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
1. install the libnss-extrausers and configure it
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1589289] Autopkgtest regression report (util-linux/2.27.1-6ubuntu3.8)
All autopkgtests for the newly accepted util-linux (2.27.1-6ubuntu3.8) for xenial have finished running. The following regressions have been reported in tests triggered by the package: chromium-browser/76.0.3809.100-0ubuntu0.16.04.1 (i386, amd64, arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#util-linux [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1589289 Title: fstrim: cannot open /dev/.lxd-mounts: Permission denied Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Committed Status in util-linux source package in Bionic: Fix Committed Status in util-linux source package in Disco: Fix Committed Status in util-linux package in Debian: Unknown Bug description: [Impact] fstrim weekly cronjob output in an unprivileged LXD container: /etc/cron.weekly/fstrim: fstrim: cannot open /dev/.lxd-mounts: Permission denied fstrim: /dev/fuse: not a directory fstrim: /dev/lxd: FITRIM ioctl failed: Operation not permitted There is a github issue: https://github.com/lxc/lxd/issues/2030 The outcome is that it's purely an fstrim misbehaviour, it could be smarter. Stephane Graber comment: As all of this is handled by the kernel, there isn't anything we can do about it in LXD. I think fstrim should be made slightly more clever: * Don't run on bind-mounts (you can detect bind-mounts by parsing /proc/self/mountinfo instead of /proc/mounts) * Maybe not be as noisy on expected errors like EACCES, EPERM and ENOENT, only log actual failures which would likely be EINVAL or memory related errors. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Sun Jun 5 19:49:04 2016 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) [Test Case] * Ubuntu lxd container * Wait for the scheduled fstrim run (X: cronjob, B and late: systemd timer) * fstrim will run and report errors "Operation not permitted" "Permission denied", ... Container shouldn't run fstrim, it should only be run at host level. [Potential Regression] None, the change will only block fstrim to be automatically run at scheduled time. One can still run fstrim on a container manually, even if there is no purpose of doing that. Xenial uses the cronjob approach /etc/cron.weekly/fstrim Bionic and late switched to a systemd timer. 2 differents fixes (one for X, and one for B and late) will be needed, but they'll do same thing, which prevent fstrim to automatically run if inside a container both fixes using systemd-virt-detect. [Other Informations] * The systemd timer change upstream PR: https://github.com/karelzak/util-linux/pull/841 https://github.com/karelzak/util-linux/commit/0280d31a2bd6292acd9a4b86d0f6b5feb275a618 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1589289/+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 1589289] Autopkgtest regression report (util-linux/2.33.1-0.1ubuntu3)
All autopkgtests for the newly accepted util-linux (2.33.1-0.1ubuntu3) for disco have finished running. The following regressions have been reported in tests triggered by the package: systemd/240-6ubuntu5.3 (amd64, ppc64el) openjdk-8/8u222-b10-1ubuntu1~19.04.1 (armhf, arm64, amd64, s390x, i386, ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#util-linux [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1589289 Title: fstrim: cannot open /dev/.lxd-mounts: Permission denied Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Committed Status in util-linux source package in Bionic: Fix Committed Status in util-linux source package in Disco: Fix Committed Status in util-linux package in Debian: Unknown Bug description: [Impact] fstrim weekly cronjob output in an unprivileged LXD container: /etc/cron.weekly/fstrim: fstrim: cannot open /dev/.lxd-mounts: Permission denied fstrim: /dev/fuse: not a directory fstrim: /dev/lxd: FITRIM ioctl failed: Operation not permitted There is a github issue: https://github.com/lxc/lxd/issues/2030 The outcome is that it's purely an fstrim misbehaviour, it could be smarter. Stephane Graber comment: As all of this is handled by the kernel, there isn't anything we can do about it in LXD. I think fstrim should be made slightly more clever: * Don't run on bind-mounts (you can detect bind-mounts by parsing /proc/self/mountinfo instead of /proc/mounts) * Maybe not be as noisy on expected errors like EACCES, EPERM and ENOENT, only log actual failures which would likely be EINVAL or memory related errors. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Sun Jun 5 19:49:04 2016 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) [Test Case] * Ubuntu lxd container * Wait for the scheduled fstrim run (X: cronjob, B and late: systemd timer) * fstrim will run and report errors "Operation not permitted" "Permission denied", ... Container shouldn't run fstrim, it should only be run at host level. [Potential Regression] None, the change will only block fstrim to be automatically run at scheduled time. One can still run fstrim on a container manually, even if there is no purpose of doing that. Xenial uses the cronjob approach /etc/cron.weekly/fstrim Bionic and late switched to a systemd timer. 2 differents fixes (one for X, and one for B and late) will be needed, but they'll do same thing, which prevent fstrim to automatically run if inside a container both fixes using systemd-virt-detect. [Other Informations] * The systemd timer change upstream PR: https://github.com/karelzak/util-linux/pull/841 https://github.com/karelzak/util-linux/commit/0280d31a2bd6292acd9a4b86d0f6b5feb275a618 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1589289/+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 1740894] Autopkgtest regression report (systemd/237-3ubuntu10.26)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.26) for bionic have finished running. The following regressions have been reported in tests triggered by the package: network-manager/1.10.6-2ubuntu1.1 (arm64) dovecot/1:2.2.33.2-1ubuntu4.3 (armhf) systemd/237-3ubuntu10.26 (ppc64el) gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1740894 Title: KEY_RFKILL is not passed to userspace Status in OEM Priority Project: Fix Released Status in OEM Priority Project bionic series: Fix Released Status in libxkbcommon package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in xkeyboard-config package in Ubuntu: Fix Released Status in xorgproto package in Ubuntu: Fix Released Status in libxkbcommon source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Committed Status in xkeyboard-config source package in Bionic: Fix Committed Status in xorgproto source package in Bionic: Fix Released Status in libxkbcommon source package in Cosmic: Fix Released Status in xkeyboard-config source package in Cosmic: Fix Released Status in xorgproto source package in Cosmic: Fix Released Bug description: * Impact the airplane mode key doesn't work in GNOME * Test case Use a laptop with a key to activate airplane mode, it should toggle the corresponding mode on/off when used * Regression potential The change adds a new key definition but doesn't touch any existing one, nothing specific to test out of the new key working - There are a couple things going on, that could be fixed by a Debian or Ubuntu maintainer: - libxkbdcommon needs to be updated from 0.7.1 to 0.7.2. This introduces the RFKill key: https://lists.freedesktop.org/archives /wayland-devel/2017-August/034721.html - x11-proto needs a new release. This commit added RFKill, but it is not in a release: https://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=98a32d328e7195e12c38baa877917335bceffbaf - Likely other X11 packages need to be rebuilt. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1740894/+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 1589289] Autopkgtest regression report (util-linux/2.31.1-0.4ubuntu3.4)
All autopkgtests for the newly accepted util-linux (2.31.1-0.4ubuntu3.4) for bionic have finished running. The following regressions have been reported in tests triggered by the package: network-manager/1.10.6-2ubuntu1.1 (arm64) openjdk-8/8u222-b10-1ubuntu1~18.04.1 (arm64, ppc64el, armhf, i386, amd64, s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#util-linux [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1589289 Title: fstrim: cannot open /dev/.lxd-mounts: Permission denied Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Committed Status in util-linux source package in Bionic: Fix Committed Status in util-linux source package in Disco: Fix Committed Status in util-linux package in Debian: Unknown Bug description: [Impact] fstrim weekly cronjob output in an unprivileged LXD container: /etc/cron.weekly/fstrim: fstrim: cannot open /dev/.lxd-mounts: Permission denied fstrim: /dev/fuse: not a directory fstrim: /dev/lxd: FITRIM ioctl failed: Operation not permitted There is a github issue: https://github.com/lxc/lxd/issues/2030 The outcome is that it's purely an fstrim misbehaviour, it could be smarter. Stephane Graber comment: As all of this is handled by the kernel, there isn't anything we can do about it in LXD. I think fstrim should be made slightly more clever: * Don't run on bind-mounts (you can detect bind-mounts by parsing /proc/self/mountinfo instead of /proc/mounts) * Maybe not be as noisy on expected errors like EACCES, EPERM and ENOENT, only log actual failures which would likely be EINVAL or memory related errors. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Sun Jun 5 19:49:04 2016 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) [Test Case] * Ubuntu lxd container * Wait for the scheduled fstrim run (X: cronjob, B and late: systemd timer) * fstrim will run and report errors "Operation not permitted" "Permission denied", ... Container shouldn't run fstrim, it should only be run at host level. [Potential Regression] None, the change will only block fstrim to be automatically run at scheduled time. One can still run fstrim on a container manually, even if there is no purpose of doing that. Xenial uses the cronjob approach /etc/cron.weekly/fstrim Bionic and late switched to a systemd timer. 2 differents fixes (one for X, and one for B and late) will be needed, but they'll do same thing, which prevent fstrim to automatically run if inside a container both fixes using systemd-virt-detect. [Other Informations] * The systemd timer change upstream PR: https://github.com/karelzak/util-linux/pull/841 https://github.com/karelzak/util-linux/commit/0280d31a2bd6292acd9a4b86d0f6b5feb275a618 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1589289/+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 1837700] Autopkgtest regression report (systemd/240-6ubuntu5.4)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.4) for disco have finished running. The following regressions have been reported in tests triggered by the package: ndctl/unknown (armhf) tinyssh/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf) polkit-qt-1/0.112.0-6 (armhf) gvfs/1.40.1-1ubuntu0.1 (amd64, i386) systemd/240-6ubuntu5.4 (amd64, s390x, i386, ppc64el) php7.2/7.2.19-0ubuntu0.19.04.2 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1837700 Title: Dell system takes a long time to connect network with external dock Status in HWE Next: New Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: update for SRU process: [Impact] 1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system occasionally install two USB ethernet with same MAC address, the system will suffer 90 seconds for network interface renaming mechanism before the last USB ethernet interface to activate. [Test Case] 1. Install ubuntu on Dell laptop. 2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users can observe the last one will take 90 seconds for renaming to rename0. 3. Users can also find that the two USB ethernet have the same MAC address. [Regression Potential] To resolve the issue, drop a debian patch from systemd package. The debian patch is to revert an upstream commit to support 75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated, the regression potential should be relatively low. --- Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0
[Touch-packages] [Bug 1830796] Autopkgtest regression report (gdb/8.1-0ubuntu3.1)
All autopkgtests for the newly accepted gdb (8.1-0ubuntu3.1) for bionic have finished running. The following regressions have been reported in tests triggered by the package: apport/2.20.9-0ubuntu7.7 (amd64) python3.6/3.6.8-1~18.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#gdb [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1830796 Title: [Bionic][ARM64]Failure debugging linux kernel Status in gdb package in Ubuntu: Fix Released Status in gdb source package in Bionic: Fix Committed Bug description: [Impact] GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For example it is unable to print values of variables like 'jiffies_64'. [Test] # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic /proc/kcore [New process 1] Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic root=UUID=edb5e5a7-8272-4e13-aa25-37'. #0 0x in ?? () (gdb) p jiffies_64 Cannot access memory at address 0x09616980 (gdb) [Fix] This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by the following patch: 8727de56b0 Fix tagged pointer support [Regression Potential] The risk of regression after applying this patch could be to architectures other than ARM64 due to changes to gdb/util.c. Please see comment #2 where I have tested the PPA package on a ppc64el system and found it does not introduce any regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1830796/+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 1837700] Autopkgtest regression report (systemd/237-3ubuntu10.26)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.26) for bionic have finished running. The following regressions have been reported in tests triggered by the package: network-manager/1.10.6-2ubuntu1.1 (arm64) dovecot/1:2.2.33.2-1ubuntu4.3 (armhf) systemd/237-3ubuntu10.26 (ppc64el) gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1837700 Title: Dell system takes a long time to connect network with external dock Status in HWE Next: New Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: update for SRU process: [Impact] 1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system occasionally install two USB ethernet with same MAC address, the system will suffer 90 seconds for network interface renaming mechanism before the last USB ethernet interface to activate. [Test Case] 1. Install ubuntu on Dell laptop. 2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users can observe the last one will take 90 seconds for renaming to rename0. 3. Users can also find that the two USB ethernet have the same MAC address. [Regression Potential] To resolve the issue, drop a debian patch from systemd package. The debian patch is to revert an upstream commit to support 75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated, the regression potential should be relatively low. --- Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03
[Touch-packages] [Bug 1817537] Autopkgtest regression report (libsoup2.4/2.62.1-1ubuntu0.3)
All autopkgtests for the newly accepted libsoup2.4 (2.62.1-1ubuntu0.3) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#libsoup2.4 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsoup2.4 in Ubuntu. https://bugs.launchpad.net/bugs/1817537 Title: libsoup should support ntlmv2 Status in libsoup2.4 package in Ubuntu: Fix Released Status in libsoup2.4 source package in Bionic: Fix Committed Bug description: * Impact Without NTLMv2 support evolution-ews can't connect to some exchange servers * Test case Try connecting from evolution-ews to an exchange server which enforces NTLMV2 * Regression potential The change adds extra cases in the ntlm handling support, it should impact existing feature but check out for any potential regression in libsoup user (check at least evolution and epiphany-browser). Note that the patch include additional code tests --- Our Exchange admins recently made NTLMv2 obligatory. Since then interaction with Exchange through Evolution isn't possible anymore. In newer versions of libsoup that has been implemented, see https://gitlab.gnome.org/GNOME/evolution-ews/issues/38 Could that be backported to Ubuntu 18.04? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libsoup2.4-1 2.62.1-1ubuntu0.1 ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18 Uname: Linux 4.15.0-45-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Feb 25 12:10:26 2019 SourcePackage: libsoup2.4 UpgradeStatus: Upgraded to bionic on 2018-09-27 (150 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsoup2.4/+bug/1817537/+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 1813581] Autopkgtest regression report (gpgme1.0/1.10.0-1ubuntu2.1)
All autopkgtests for the newly accepted gpgme1.0 (1.10.0-1ubuntu2.1) for bionic have finished running. The following regressions have been reported in tests triggered by the package: libreoffice/1:6.0.7-0ubuntu0.18.04.8 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#gpgme1.0 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1813581 Title: gpgme1.0 ftbfs in 18.04 LTS Status in gpgme1.0 package in Ubuntu: Won't Fix Status in gpgme1.0 source package in Bionic: Fix Committed Bug description: [Impact] according to http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html gpgme1.0 ftbfs. * Start testing of TofuInfoTest * Config: Using QtTest library 5.9.5, Qt 5.9.5 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.3.0) PASS : TofuInfoTest::initTestCase() PASS : TofuInfoTest::testTofuNull() PASS : TofuInfoTest::testTofuInfo() PASS : TofuInfoTest::testTofuSignCount() PASS : TofuInfoTest::testTofuKeyList() PASS : TofuInfoTest::testTofuPolicy() FAIL! : TofuInfoTest::testTofuConflict() 'sig.validity() == Signature::Marginal' returned FALSE. () Loc: [t-tofuinfo.cpp(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 2386ms * Finished testing of TofuInfoTest * FAIL: t-tofuinfo [Test case] build it [Regression potential] This only changes the test suite run during build, and that one currently fails, so it can't cause any regression. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581/+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 1830629] Autopkgtest regression report (libarchive/3.2.2-3.1ubuntu0.4)
All autopkgtests for the newly accepted libarchive (3.2.2-3.1ubuntu0.4) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#libarchive [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libarchive in Ubuntu. https://bugs.launchpad.net/bugs/1830629 Title: Errors when extracting ZIP files. It can not differentiate between files and directories Status in libarchive package in Ubuntu: Fix Released Status in libarchive source package in Bionic: Fix Committed Bug description: * Impact The bionic version has a known problem when reading file entries in ZIP files, where it incorrectly identifies directories and files entries. * Test case $ wget https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1830629/+attachment/5268728/+files/example.zip $ bsdtar -vxf example.zip $ ls -l The 'ABCD_1234' and 'empty' entries should be directories * Regression potential Check that extracting zips from bsdtar or nautilus work without issue It has been confirmed that the previous and following versions (3.3.1+) do not have this problem and the library handles the ZIP files correctly. Is it possible to include a newer version of libarchive (3.3.1+) in Bionic? This problem is seriously affecting some of our systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1830629/+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 1837734] Autopkgtest regression report (nss/2:3.35-2ubuntu2.4)
All autopkgtests for the newly accepted nss (2:3.35-2ubuntu2.4) for bionic have finished running. The following regressions have been reported in tests triggered by the package: openjdk-8/8u222-b10-1ubuntu1~18.04.1 (i386) chrony/3.2-4ubuntu4.2 (arm64, ppc64el, armhf, i386, amd64, s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#nss [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/1837734 Title: Firefox crash on a FIPS enabled machine due to libnss3 Status in nss package in Ubuntu: Fix Released Status in nss source package in Xenial: Fix Committed Status in nss source package in Bionic: Fix Committed Status in nss source package in Disco: Fix Committed Status in nss source package in Eoan: Fix Released Bug description: [IMPACT] nss is not a FIPS certified library. On a machine running FIPS enabled kernel, the library by default goes into FIPS mode if /proc/sys/crypto/fips_enabled=1. This is an untested configuration and since libnss3 is not a certified library we propose disabling reading the 'fips_enabled' flag and therefore switching the library automatically into FIPS mode. A FIPS customer reported firefox crash on a FIPS enabled system and strace showed it was repeatedly trying to read the fips_enabled flag from libnss3 before crashing. The proposed patch disables reading the /proc/sys/crypto/fips_enabled flag. The users of the library however can force nss into FIPS mode via an environment variable. We plan to leave it as is so as not to regress existing users who may be using it. The issue impacts libnss3 versions in eoan, disco, bionic and xenial. lsb_release -rd Description: Ubuntu Eoan Ermine (development branch) Release: 19.10 Version: 2:3.45-1ubuntu1 lsb_release -rd Description: Ubuntu Disco Dingo Release: 19.04 Version: 2:3.42-1ubuntu2 lsb_release -rd Description: Ubuntu Bionic Beaver Release: 18.04 Version: 2:3.35-2ubuntu2.3 lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 Version: 2:3.28.4-0ubuntu0.16.04 [FIX] This fix proposes to disable libnss3 reading proc/sys/crypto/fips_enabled. We only want fips certified modules reading this file and running in fips mode. libnss3 is not one of our fips certified modules, so should not be reading this along with our fips certified modules to determine whether to run in fips mode. Users who do want to run the library in FIPS mode can do so by using the environment variable "NSS_FIPS". We propose to leave it as is so as not to regress anyone using this. The user who is using this option should be doing so with the awareness. [TEST] Tested on a xenial and bionic desktop ISO running FIPS enabled kernel and in FIPS mode. With the patch fix no crashes were observed when launching firefox browser. Without the patch fix, firefox crashes. Tested on a xenial and bionic desktop ISO running non-FIPS generic kernel. With the patch fix, firefox worked as expected and no changes were observed. [REGRESSION POTENTIAL] The regression potential for this is small. A FIPS kernel is required to create /proc/sys/crypto/fips_enabled and it is not available in standard ubuntu archive. For users forcing FIPS through environment variable, nothing has changed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1837734/+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 1841412] Autopkgtest regression report (mesa/19.0.8-0ubuntu0~18.04.2)
All autopkgtests for the newly accepted mesa (19.0.8-0ubuntu0~18.04.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: vtk6/unknown (armhf) kf5-messagelib/4:17.12.3-0ubuntu3 (armhf) firefox/68.0.2+build1-0ubuntu0.18.04.1 (armhf) openjdk-8/8u222-b10-1ubuntu1~18.04.1 (i386, s390x, arm64, armhf, ppc64el, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#mesa [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1841412 Title: Build with NDEBUG again Status in mesa package in Ubuntu: Invalid Status in mesa source package in Bionic: Fix Committed Bug description: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that some asserts are enabled, and at least nouveau is affected. [Test case] chech the build log that -DNDEBUG is passed [Regression potential] none really, it just adds a build flag which should've been there To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1841412/+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 1815172] Autopkgtest regression report (mesa/19.0.8-0ubuntu0~18.04.2)
All autopkgtests for the newly accepted mesa (19.0.8-0ubuntu0~18.04.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: vtk6/unknown (armhf) kf5-messagelib/4:17.12.3-0ubuntu3 (armhf) firefox/68.0.2+build1-0ubuntu0.18.04.1 (armhf) openjdk-8/8u222-b10-1ubuntu1~18.04.1 (i386, s390x, arm64, armhf, ppc64el, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#mesa [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1815172 Title: [bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa Status in Mesa: Fix Released Status in linux package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in mesa source package in Bionic: Fix Committed Status in linux source package in Cosmic: Won't Fix Status in mesa source package in Cosmic: Fix Released Bug description: [Impact] Several schools reported black screens after normally updating their Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1. Downgrading mesa fixes the problem. lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:8694]Kernel modules: i915 Unfortunately I can't find a lot of useful information, here are some bits: * systemctl --failed says "gpu-manager" and "lightdm" have failed * Xorg.log is clean: https://termbin.com/6l2b * dmesg too: https://termbin.com/ip4e * It happens on lightdm/MATE, I don't know about Ubuntu GNOME. * If one runs `xinit` from ssh, it fails with: i965: Failed to submit batchbuffer: Invalid argument This is caused by mesa assuming that soft-pinning on GEN8+ is working since kernel 4.5, but in fact this issue wasn't fixed until 4.19.3. So a proper fix would be to backport commits from 4.19.3/4.20 to fix GTT sizes/pin flags, but that's left for future. [Test case] install fixed mesa or kernel, check that the regression is fixed [Regression potential] mesa: shouldn't be any, it just reverts the change to always soft-pin (TODO kernel: adds commits from upstream stable, which have been well tested upstream by now) To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815172/+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 1829860] Autopkgtest regression report (apt/1.8.3)
All autopkgtests for the newly accepted apt (1.8.3) for disco have finished running. The following regressions have been reported in tests triggered by the package: auto-apt-proxy/11 (armhf) reprotest/0.7.8 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: New Status in apt source package in Bionic: New Status in apt source package in Disco: Fix Committed Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] Watch lock release with strace and see that it unlocks the right way. [Regression potential] Some other locking races or something? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1838771] Autopkgtest regression report (apt/1.8.3)
All autopkgtests for the newly accepted apt (1.8.3) for disco have finished running. The following regressions have been reported in tests triggered by the package: auto-apt-proxy/11 (armhf) reprotest/0.7.8 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1838771 Title: http:Fix Host header in proxied https connections Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: In Progress Status in apt source package in Disco: Fix Committed Bug description: [Impact] Currently CONNECT requests use the name of the proxy as Host value, instead of the origin server's name. According to RFC 2616 "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL." The current implementation causes problems with some proxy vendors. This commit[0] fixes this. [0] - https://salsa.debian.org/apt- team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f [Test Case] Here's one reproducer an impacted user brought to my attention: # /etc/environment http_proxy="http://internal:8080; https_proxy="http://interal:8080; To support application development activities in-house, I had to configure Azure CLI APT repository following the instructions from "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view =azure-cli-latest": $ sudo apt-get update $ sudo apt-get install curl apt-transport-https lsb-release gnupg $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \ $ gpg --dearmor | \ $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null $ AZ_REPO=$(lsb_release -cs) $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ AZ_REPO main" | \ $ sudo tee /etc/apt/sources.list.d/azure-cli.list $ sudo apt update In the final "apt update" command, APT respects system-wide network proxy variables and successfully fetched Canonical repository data over HTTP. However, it was unable to fetch the newly added Microsoft packages repository served via HTTPS. By using Wireshark to examine the HTTPS request made by APT, the request body reveals as: CONNECT packages.microsoft.com:443 HTTP/1.1\r\n Host: internal:8080\r\n User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n ... ... There also is an automated test case in the package that runs as part of autopkgtest that tests a scenario like this, see the commit. [Regression Potential] * Fix already in debian, and Eoan * Has been reviewed/approved by juliank * A test package (pre-sru) has been provided to an impacted user, and he confirms it solves the situation. [Other Info] # salsa $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72 1.9.0~8 # rmadison apt => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1756595] Autopkgtest regression report (apt/1.8.3)
All autopkgtests for the newly accepted apt (1.8.3) for disco have finished running. The following regressions have been reported in tests triggered by the package: auto-apt-proxy/11 (armhf) reprotest/0.7.8 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1756595 Title: disk space info inadvertently provides all installed snaps Status in apport package in Ubuntu: Invalid Status in apt package in Ubuntu: Fix Released Status in apport source package in Bionic: Invalid Status in apt source package in Bionic: Triaged Status in apport source package in Disco: New Status in apt source package in Disco: Fix Committed Status in apport source package in Eoan: Invalid Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] N/A [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595/+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 1829861] Autopkgtest regression report (apt/1.8.3)
All autopkgtests for the newly accepted apt (1.8.3) for disco have finished running. The following regressions have been reported in tests triggered by the package: auto-apt-proxy/11 (armhf) reprotest/0.7.8 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: New Status in apt source package in Disco: Fix Committed Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] We don't really have a reproducer. You'd need a server that re-negotiates by path; e.g. because it requires a a certain client certificate for a certain path. We know it does not break other use cases, having run that for quite some time in eoan and Debian stretch, and the patch was tested by the patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93). [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 1840375] Autopkgtest regression report (shadow/1:4.2-3.1ubuntu5.5)
All autopkgtests for the newly accepted shadow (1:4.2-3.1ubuntu5.5) for xenial
have finished running.
The following regressions have been reported in tests triggered by the package:
nvidia-graphics-drivers-340/unknown (armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#shadow
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
New
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Xenial:
Fix Committed
Status in shadow source package in Bionic:
Fix Committed
Status in shadow source package in Disco:
Fix Committed
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
1. install the libnss-extrausers and configure it
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1756595] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1756595 Title: disk space info inadvertently provides all installed snaps Status in apport package in Ubuntu: Invalid Status in apt package in Ubuntu: Fix Released Status in apport source package in Bionic: Invalid Status in apt source package in Bionic: Fix Committed Status in apport source package in Disco: New Status in apt source package in Disco: Fix Committed Status in apport source package in Eoan: Invalid Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] Do something that triggers the apport hook and make sure you don't see snaps in there. For example, install xterm, then add exit 1 to the start of the prerm, then run apt remove xterm, and investigate /var/crash/xterm.0.crash after that (delete before running apt). [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595/+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 1838771] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1838771 Title: http:Fix Host header in proxied https connections Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] Currently CONNECT requests use the name of the proxy as Host value, instead of the origin server's name. According to RFC 2616 "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL." The current implementation causes problems with some proxy vendors. This commit[0] fixes this. [0] - https://salsa.debian.org/apt- team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f [Test Case] Here's one reproducer an impacted user brought to my attention: # /etc/environment http_proxy="http://internal:8080; https_proxy="http://interal:8080; To support application development activities in-house, I had to configure Azure CLI APT repository following the instructions from "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view =azure-cli-latest": $ sudo apt-get update $ sudo apt-get install curl apt-transport-https lsb-release gnupg $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \ $ gpg --dearmor | \ $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null $ AZ_REPO=$(lsb_release -cs) $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ AZ_REPO main" | \ $ sudo tee /etc/apt/sources.list.d/azure-cli.list $ sudo apt update In the final "apt update" command, APT respects system-wide network proxy variables and successfully fetched Canonical repository data over HTTP. However, it was unable to fetch the newly added Microsoft packages repository served via HTTPS. By using Wireshark to examine the HTTPS request made by APT, the request body reveals as: CONNECT packages.microsoft.com:443 HTTP/1.1\r\n Host: internal:8080\r\n User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n ... ... There also is an automated test case in the package that runs as part of autopkgtest that tests a scenario like this, see the commit. [Regression Potential] * Fix already in debian, and Eoan * Has been reviewed/approved by juliank * A test package (pre-sru) has been provided to an impacted user, and he confirms it solves the situation. [Other Info] # salsa $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72 1.9.0~8 # rmadison apt => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+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 1829860] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: New Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] Watch lock release with strace and see that it unlocks the right way. [Regression potential] Some other locking races or something? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1829861] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] We don't really have a reproducer. You'd need a server that re-negotiates by path; e.g. because it requires a a certain client certificate for a certain path. We know it does not break other use cases, having run that for quite some time in eoan and Debian stretch, and the patch was tested by the patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93). [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 520546] Autopkgtest regression report (kbd/2.0.4-4ubuntu1.19.04.0)
All autopkgtests for the newly accepted kbd (2.0.4-4ubuntu1.19.04.0) for disco have finished running. The following regressions have been reported in tests triggered by the package: systemd/240-6ubuntu5 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#kbd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kbd in Ubuntu. https://bugs.launchpad.net/bugs/520546 Title: [SRU]Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT switch from Alt+Left/Right Status in console-setup package in Ubuntu: Fix Released Status in kbd package in Ubuntu: Fix Released Status in xorg-server package in Ubuntu: Invalid Status in console-setup source package in Xenial: Confirmed Status in kbd source package in Xenial: Won't Fix Status in xorg-server source package in Xenial: Confirmed Status in console-setup source package in Bionic: Fix Released Status in kbd source package in Bionic: Won't Fix Status in linux source package in Bionic: Confirmed Status in xorg-server source package in Bionic: Invalid Status in console-setup source package in Cosmic: Fix Released Status in kbd source package in Cosmic: Fix Committed Status in linux source package in Cosmic: Confirmed Status in xorg-server source package in Cosmic: Invalid Status in console-setup source package in Disco: Fix Released Status in kbd source package in Disco: Won't Fix Status in linux source package in Disco: Confirmed Status in xorg-server source package in Disco: Invalid Status in console-setup source package in Eoan: Fix Released Status in kbd source package in Eoan: Fix Released Status in linux source package in Eoan: Confirmed Status in xorg-server source package in Eoan: Invalid Bug description: (kbd) [Impact] * kbd_mode -u is documented to break keyboards in modes other than xlate and unicode, while it is still called by some scripts. Those scripts are called transitively by maintainer scripts such as the one already fixed in console-setup. * To avoid accidentally breaking keyboards a -f option is added to force such breaking mode changes. Without -f only the safe mode changes are performed and an error is printed when the requested mode change is not safe. Next upstream version will also exit with error, but the cherry-picked fix makes kbd_mode return success even when the mode switch is not performed to avoid regressions of scripts. [Test case] * Verify that safe mode switches work and dangerous ones are skipped without -f. Please note that the test will temporarily break the system's keyboard and it is recommended to run the test in a VM. rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $? The keyboard is in Unicode (UTF-8) mode 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $? 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $? 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4 The keyboard is in xlate (8-bit) mode rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $? 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4 The keyboard is in Unicode (UTF-8) mode rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $? The keyboard is in some unknown mode Changing to the requested mode may make your keyboard unusable, please use -f to force the change. 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $? 0 rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0 The keyboard is in Unicode (UTF-8) mode rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0 rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0 The keyboard is in raw (scancode) mode rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $? The keyboard is in raw (scancode) mode Changing to the requested mode may make your keyboard unusable, please use -f to force the change. 0 [Regression Potential] * kbd_mode stops performing breaking mode switches and this may make scripts ineffective when trying to perform a breaking change. This is the intention of the change and the emitter error helps in finding the offending script. The following packages found to call kbd_mode directly: console-setup xinit console-cyrillic initramfs-tools dracut console-tools xview ubiquity's embedded console-setup copy console-data vnc4 The console related packages are expected to execute only safe mode changes because they should operate on consoles only and the rest seem to be safe, too. (console-setup) [Impact] * keyboard-configuration's
[Touch-packages] [Bug 1844524] Autopkgtest regression report (grep/3.1-2build1)
All autopkgtests for the newly accepted grep (3.1-2build1) for bionic have finished running. The following regressions have been reported in tests triggered by the package: util-linux/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#grep [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: Invalid Status in grep source package in Bionic: Fix Committed Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1773859] Autopkgtest regression report (systemd/237-3ubuntu10.31)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) netplan.io/0.97-0ubuntu1~18.04.1 (amd64) apt/1.6.12 (arm64, ppc64el) pulseaudio/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd-shim in Ubuntu. https://bugs.launchpad.net/bugs/1773859 Title: upgrades to 18.04 fail Status in systemd package in Ubuntu: Fix Released Status in systemd-shim package in Ubuntu: Won't Fix Status in systemd source package in Bionic: Fix Committed Status in systemd-shim source package in Bionic: Won't Fix Status in systemd source package in Cosmic: Fix Released Status in systemd-shim source package in Cosmic: Won't Fix Bug description: [Impact] * Some systems fail to upgrade due to conflicts between systemd and the (now removed from the archive) systemd-shim / upstart. * Instead of trying to work out what's the problem in ordering / removal of diverts, ensure that systemd is never unpacked whilst systemd-shim/upstart are still on disk. Thus declare conflicts against systemd-shim/upstart packages in systemd package. [Test Case] * monitor drop-off of upgrades with below reported problem * Check that it is possible to upgrade to bionic's libpam-systemd from xenial with systemd-shim installed on xenial, ie. lxc launch ubuntu-daily:xenial test-shim-upgrade lxc exec test-shim-upgrade apt update apt install systemd-shim wget https://deb.debian.org/debian/pool/main/s/systemd-shim/systemd-shim_10-3_amd64.deb apt install ./systemd-shim_10-3_amd64.deb sed 's/xenial/bionic/' -i /etc/apt/sources.list apt update apt install systemd this currently passes, however, systemd-shim remains installed. It should be removed instead. Apt install systemd should have lines like this: The following packages will be REMOVED: systemd-shim ... Removing 'diversion of /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service to /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.systemd by systemd-shim' ... [Regression Potential] * systemd-shim/upstart are both removed and not supported in bionic, thus forcing their removal via conflicts should bring the system into an expected state. [Other Info] * original bug report $ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be REMOVED: systemd-shim 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 71.7 kB disk space will be freed. Do you want to continue? [Y/n] y (Reading database ... 63 files and directories currently installed.) Removing systemd-shim (9-1bzr4ubuntu1) ... Removing 'diversion of /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service to /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.systemd by systemd-shim' dpkg-divert: error: rename involves overwriting '/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service' with different file '/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.systemd', not allowed dpkg: error processing package systemd-shim (--remove): subprocess installed post-removal script returned error exit status 2 Errors were encountered while processing: systemd-shim E: Sub-process /usr/bin/dpkg returned an error code (1) Commenting out the dpkg-divert in systemd-shim's postrm solved this for me and I was about to continue the upgrade. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1773859/+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 1773148] Autopkgtest regression report (systemd/237-3ubuntu10.31)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) netplan.io/0.97-0ubuntu1~18.04.1 (amd64) apt/1.6.12 (arm64, ppc64el) pulseaudio/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1773148 Title: /lib/systemd/systemd- journald:6:fsync:fsync_directory_of_file:journal_file_rotate:do_rotate:server_rotate Status in systemd: New Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * systemd aborts journald, upon watchdog expiry and generates lots of crash reports * it appears that journald is simply stuck in fsync * it has been agreed to disable watchdog timer on journald [Test Case] * watch drop-off of errors w.r.t. watchdog timer [Regression Potential] * Potentially journald does get stuck, and thus is no longer automatically restarted with a sigabrt crash. However, so far, it is not known to do that. [Other Info] * Original bug report The Ubuntu Error Tracker has been receiving reports about a problem regarding systemd. This problem was most recently seen with package version 237-3ubuntu10, the problem page at https://errors.ubuntu.com/problem/ff29f7ff39be0e227f0187ad72e5d458e95f6fcf 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/systemd/+bug/1773148/+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 1776626] Autopkgtest regression report (systemd/237-3ubuntu10.31)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) netplan.io/0.97-0ubuntu1~18.04.1 (amd64) apt/1.6.12 (arm64, ppc64el) pulseaudio/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1776626 Title: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part Status in Ubuntu on IBM z Systems: Fix Released Status in cryptsetup package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cryptsetup source package in Bionic: Won't Fix Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] * cryptsetup in bionic supports creating luks volumes with a non- standard sector-size option, and thus this option also needs to be used when activating the LUKS volumes. Add sector-size= option support to /etc/crypttab. [Test Case] * Create a plain LUKS volume with sector-size 4096 * Specify sector-size=4096 option in /etc/crypttab * reload systemd, start systemd-cryptsetup@.service for that volume * check the journal, to ensure that `sector-size` option was recognized and is active. (i.e. there is not error messages about unrecognized option `sector-size` from systemd-cryptsetup) [Regression Potential] * This is an optional argument, not used by default. Currently custom sector-size crypttab does not work correctly, and thus cannot regress. [Other Info] * Original bug report Support fast clear key dm-crypt with 4k support Extend /etc/crypttab to enable 4k sector support in plain mode The proposed enhancements are posted on github, see https://github.com/systemd/systemd/issues/8881 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1776626/+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 1671951] Autopkgtest regression report (systemd/237-3ubuntu10.31)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) netplan.io/0.97-0ubuntu1~18.04.1 (amd64) apt/1.6.12 (arm64, ppc64el) pulseaudio/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1670291] Autopkgtest regression report (systemd/237-3ubuntu10.31)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.31) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) netplan.io/0.97-0ubuntu1~18.04.1 (amd64) apt/1.6.12 (arm64, ppc64el) pulseaudio/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1670291 Title: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot Status in landscape-client package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in landscape-client source package in Trusty: Fix Released Status in systemd source package in Trusty: New Status in landscape-client source package in Xenial: Fix Released Status in systemd source package in Xenial: Fix Released Status in landscape-client source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Committed Status in landscape-client source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: https://github.com/systemd/systemd/pull/10061 [Impact] * When logind is not available, shutdown command fails to schedule a shutdown, and despite its intentions to immediately shutdown, does not do so. [Test Case] sudo systemctl mask systemd-logind.service sudo systemctl stop systemd-logind.service shutdown +1 The expectation is that system goes to shutdown. It is buggy if the system remains up - i.e. command returns to shell with exit code 1. [Regression Potential] * It is a corner case to run against systemd-shim logind / or logind not otherwise available. The function still performs a clean-shutdown, and should not cause loss of work. [Other Info] * Original bug report, running against systemd-shim/systemd-service post trusty->xenial upgrade, pre-reboot. Used Landscape (Paid Canonical Subscription) to upgrade one of my machines. Landscape only shows "In Progress" for more than 8 hours now and asked for a reboot of the machine in a second alert. In the reboot attempt I get the message: = Failed to set wall message, ignoring: Method "SetWallMessage" with signature "sb" on interface "org.freedesktop.login1.Manager" doesn't exist Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Method "ScheduleShutdown" with signature "st" on interface "org.freedesktop.login1.Manager" doesn't exist = Steps to reproduce: * Fully updated 14.04.5 machine * Open Landscape * Choose the machine * Choose Packages * This computer can be upgraded to a newer release * Apply * Wait 2 hours * Alert comes in a seperate Landscape message Machine is ready for reboot * Choose Info... Power * Deliver to selected computers as soon as possible * Error message I found this thread on reddit about this issue maybe the solution can be built into the upgrade script https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+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 1844634] Autopkgtest regression report (apt/1.8.4)
All autopkgtests for the newly accepted apt (1.8.4) for disco have finished running. The following regressions have been reported in tests triggered by the package: reprotest/0.7.8 (s390x) gcc-snapshot/unknown (armhf) apt/1.8.4 (amd64, armhf, s390x, ppc64el, arm64, i386) autopkgtest/5.10ubuntu1 (amd64, i386) gcc-7/7.4.0-8ubuntu1 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1844634 Title: Removals keep removing dependencies if removal of a package fails Status in apt package in Ubuntu: Fix Released Status in apt source package in Disco: Fix Committed Status in apt package in Debian: Fix Released Bug description: [Impact] Assuming packages A and B, with A depending on B. A has a failing prerm script. Expected behavior: - A fails to be removed, A and B stay unchanged Actual behavior: - A fails to be removed - B is still removed This might crash their system (e.g. if A is systemd and B is libsystemd0). [Test case] See Impact. An automated version of the test case (test-apt-get-remove-depends) is included and run on autopkgtest. [Regression potential] We now abort earlier in removal failures, that might be harder to recover from or not, nobody really knows. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1844634/+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 1840995] Autopkgtest regression report (apt/1.8.4)
All autopkgtests for the newly accepted apt (1.8.4) for disco have finished
running.
The following regressions have been reported in tests triggered by the package:
reprotest/0.7.8 (s390x)
gcc-snapshot/unknown (armhf)
apt/1.8.4 (amd64, armhf, s390x, ppc64el, arm64, i386)
autopkgtest/5.10ubuntu1 (amd64, i386)
gcc-7/7.4.0-8ubuntu1 (armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#apt
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1840995
Title:
check_stamp() function of apt.systemd.daily should not assume interval
is a number
Status in apt package in Ubuntu:
Fix Released
Status in apt source package in Disco:
Fix Committed
Bug description:
[Impact]
Warning messages when using suffixes in intervals such as d for day
/usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h
[Test case]
Create 99local in apt.conf.d with
APT::Periodic::Update-Package-Lists "1d";
and run /usr/lib/apt/apt.systemd.daily - make sure no warning appears.
[Regression potential]
The fix replaces -eq 0 checks with = 0 checks which might have different
behavior in case -eq also accepts some values as equal to 0 that are not
literally 0 and that now no longer match. But then you'd have to do stuff like
set the interval to "+0", and it seems unrealistic people do that.
[Original bug report]
In the second half of the function there is
# Calculate the interval in seconds depending on the unit specified
if [ "${interval%s}" != "$interval" ] ; then
interval="${interval%s}"
elif [ "${interval%m}" != "$interval" ] ; then
interval="${interval%m}"
interval=$((interval*60))
elif [ "${interval%h}" != "$interval" ] ; then
interval="${interval%h}"
interval=$((interval*60*60))
else
interval="${interval%d}"
interval=$((interval*60*60*24))
fi
so, a variable might hold something like "1d", "100m", etc.
Yet in the first there is a condition
if [ "$interval" -eq 0 ]; then
debug_echo "check_stamp: interval=0"
# treat as no time has passed
return 1
fi
which treats the value as a number and leads to
/usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1840995/+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 1845337] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1845337 Title: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service Status in qemu package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in qemu source package in Disco: Invalid Status in systemd source package in Disco: Fix Committed Bug description: [impact] due to a recent change to allow armhf tests to run lxd containers, autopkgtest for systemd on disco fails consistently. [test case] see test results, linked in original description below. [regression potential] very low, autopkgtest fix only. [other info] original description: --- Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1847527] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1847527 Title: Backport systemd-journal-remote fix PR #11953 Status in openstack-ansible: New Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Invalid Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] upstream commit 7fdb237f5473cb8fc2129e57e8a0039526dcb4fd broke remote journal upload, because it added a check to verify the Content-Length header, but the upload may use Transfer-Encoding of 'chunked' which does not specify Content-Length. [test case] see comment 5 [regression potential] this limits the Transfer-Encoding to only be either unspecified, or 'chunked'. Any other value will fail. However, journal-upload.c does not ever use any other Transfer-Encoding than 'chunked', and this fix comes from upstream and has not changed since applied there. Any regression would likely result in the failure to upload a remote journal. [other info] the commit that caused this is not included in Bionic, and the commit to fix this is already in Eoan; this is needed only in Disco. original description: -- I'm requesting that systemd 240 receive the fix in upstream PR 11953 found here https://github.com/systemd/systemd/pull/11953 This fixes remote journal shipping using systemd components. I believe only Disco (19.04) is impacted by this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1847527/+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 1843381] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion:
[Touch-packages] [Bug 1847815] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1847815 Title: storage autopkgtest is flaky Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Invalid Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] the systemd autopkgtest 'storage' is flaky. [test case] look at the autopkgtest test log and see some of them are failures due to failing 'storage' test; on re-running the test is passes. [regression potential] only an autopkgtest fix; very low if any. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847815/+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 1796501] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1840640] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have
finished running.
The following regressions have been reported in tests triggered by the package:
prometheus-bind-exporter/unknown (armhf)
php7.2/7.2.24-0ubuntu0.19.04.1 (armhf)
gvfs/1.40.1-1ubuntu0.1 (ppc64el)
pdns-recursor/unknown (armhf)
webhook/unknown (armhf)
munin/2.0.47-1ubuntu3 (armhf, arm64)
systemd/240-6ubuntu5.8 (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#systemd
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Fix Committed
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
nspawn instructions:
sudo apt install debootstrap systemd-container
sudo -i
debootstrap --arch=armhf bionic ~/bionic-tree/
systemd-nspawn -D ~/bionic-tree/
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include
#include
#include
#include
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+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 1849658] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1805183] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu
[Touch-packages] [Bug 1849733] Autopkgtest regression report (systemd/240-6ubuntu5.8)
All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running. The following regressions have been reported in tests triggered by the package: prometheus-bind-exporter/unknown (armhf) php7.2/7.2.24-0ubuntu0.19.04.1 (armhf) gvfs/1.40.1-1ubuntu0.1 (ppc64el) pdns-recursor/unknown (armhf) webhook/unknown (armhf) munin/2.0.47-1ubuntu3 (armhf, arm64) systemd/240-6ubuntu5.8 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1849608] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849608 Title: systemd resolv should separate the output of stdout and stderr Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] dhclient fails to notify resolved about DNS servers due to bash- specific redirect inside 'resolved' hook script [test case] see original description below [regression potential] any regression would likely cause resolved not to be aware of dhclient-provided dns servers [other info] This is needed only in Eoan and later; X/B/D do not have the bash- specific redirect '&>' in their hook file. original description: --- The file /etc/dhcp/dhclient-enter-hooks.d/resolved provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due to systemd-resolved is not run. This issue can be reproduced on Ubuntu Eoan: == root@eoan:~# dhclient -v Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/ens224/00:0c:29:92:d4:da Sending on LPF/ens224/00:0c:29:92:d4:da Listening on LPF/ens192/00:0c:29:92:d4:d0 Sending on LPF/ens192/00:0c:29:92:d4:d0 Listening on LPF/ens160/00:0c:29:92:d4:c6 Sending on LPF/ens160/00:0c:29:92:d4:c6 Sending on Socket/fallback DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d) DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26) DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 (xid=0x6d39545d) DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d) RTNETLINK answers: File exists d41d8cd98f00b204e9800998ecf8427e /run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or directory 5025823d750dda1f3f15e306c4a0afce /run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or directory bound to 192.168.120.4 -- renewal in 111 seconds. root@eoan:~# resolvectl status |grep DNS MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no DNSSEC NTA: 10.in-addr.arpa MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no == Attached please find the patch for this. The output for md5sum in the hook file resolv should separate the stdout and stderr so it won't compare the wrong data. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1815101] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1815101 Title: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted) Status in Keepalived Charm: New Status in netplan: Confirmed Status in heartbeat package in Ubuntu: Triaged Status in keepalived package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Status in heartbeat source package in Bionic: Triaged Status in keepalived source package in Bionic: Confirmed Status in systemd source package in Bionic: Confirmed Status in heartbeat source package in Disco: Triaged Status in keepalived source package in Disco: Confirmed Status in systemd source package in Disco: Confirmed Status in heartbeat source package in Eoan: Triaged Status in keepalived source package in Eoan: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] - ALL related HA software has a small problem if interfaces are being managed by systemd-networkd: nic restarts/reconfigs are always going to wipe all interfaces aliases when HA software is not expecting it to (no coordination between them. - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is smarter in this case because it has a service monitor that will restart the virtual IP resource, in affected node & nic, before considering a real failure, but other HA service might consider a real failure when it is not. [test case] - comment #14 is a full test case: to have 3 node pacemaker, in that example, and cause a networkd service restart: it will trigger a failure for the virtual IP resource monitor. - other example is given in the original description for keepalived. both suffer from the same issue (and other HA softwares as well). [regression potential] - this backports KeepConfiguration parameter, which adds some significant complexity to networkd's configuration and behavior, which could lead to regressions in correctly configuring the network at networkd start, or incorrectly maintaining configuration at networkd restart, or losing network state at networkd stop. - Any regressions are most likely to occur during networkd start, restart, or stop, and most likely to involve missing or incorrect ip address(es). - the change is based in upstream patches adding the exact feature we needed to fix this issue & it will be integrated with a netplan change to add the needed stanza to systemd nic configuration file (KeepConfiguration=) [other info] original description: --- Configure netplan for interfaces, for example (a working config with IP addresses obfuscated) network: ethernets: eth0: addresses: [192.168.0.5/24] dhcp4: false nameservers: search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, phone.blah.com] addresses: [10.22.11.1] eth2: addresses: - 12.13.14.18/29 - 12.13.14.19/29 gateway4: 12.13.14.17 dhcp4: false nameservers: search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, phone.blah.com] addresses: [10.22.11.1] eth3: addresses: [10.22.11.6/24] dhcp4: false nameservers: search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, phone.blah.com] addresses: [10.22.11.1] eth4: addresses: [10.22.14.6/24] dhcp4: false nameservers: search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, phone.blah.com] addresses: [10.22.11.1] eth7: addresses: [9.5.17.34/29] dhcp4: false optional: true nameservers: search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, phone.blah.com] addresses: [10.22.11.1] version: 2
[Touch-packages] [Bug 1835581] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1835581 Title: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Committed Bug description: [impact] the systemd networkd dhcp4 client sets the prefsrc for the default route added when a dhcp server provides only the gateway; but if the dhcp server provides classless route(s), those are configured instead, and the prefsrc is not set for those. Normally this is ok, but if the dhcp client system has other address(es) configured on the interface using dhcp, then the src for packets sent through a classless/static route might not be the same as the address provided by the dhcp server. If the gateway/router provided in the dhcp classless/static route(s) only allows traffic from the address provided to the dhcp client, then traffic from the dhcp client may be dropped by the gateway/router. [test case] set up a dhcp server system (e.g. ubuntu with dnsmasq installed and configured) and a dhcp client system. For example on the dhcp server, use this dnsmasq config: interface=ens8 bind-interfaces domain=test,10.10.0.0/24 dhcp-option=42,10.10.0.1 dhcp-range=test,10.10.0.10,10.10.0.100,1h On the dhcp client system, use networkd config such as: $ cat /etc/systemd/network/80-ens8.network [Match] Name=ens8 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 Address=10.10.0.5/24 Reboot the client, or restart networkd, and it should result in: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3580sec preferred_lft 3580sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024 Note that, because networkd completes the static ip configuration before the dhcp reply is returned and processed, the static address is used for the subnet-local routing. But for global routing through the gateway, the dhcp-provided address is used: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000 Now on the server, add a classless route: dhcp-option=121,0.0.0.0/0,10.10.0.1 and restart dnsmasq on the server. Then on the client, reboot. It should now have: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3585sec preferred_lft 3585sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 Now, the global route will use the static address, not the dhcp- provided address: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000 If the router, 10.10.0.1, only will forward traffic sent from the dhcp address it provided, 10.10.0.75, then this configuration will result in the client being unable to reach anything through the router, because all its packets will have a source address of 10.10.0.5, which the router would drop/reject. [regression potential] this only affects dhcp routes provided by a dhcp server using the 'static' or 'classless' route dhcp options. Since this behavior is currently the default when a system doesn't add static address(es) to interfaces that also get dhcp addresses, this is likely not a change in behavior for the vast
[Touch-packages] [Bug 1831787] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1831787 Title: Bogus routes after DHCP lease change Status in netplan: Invalid Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] networkd does not remove old route(s) after DHCP address change [test case] on a system using networkd, that is connected to a network where you can control the addresses that the DHCP server provides, setup system with networkd to get address via DHCP, e.g. [Match] Name=ens3 [Network] DHCP=ipv4 (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and corresponding route to the gateway. Then on the dhcp server, change the subnet to a different subnet. On the client, once its renews its DHCP address, the server will provide a new address in the new subnet, and the client will add a new default route to the new gateway address. However, the old default route to the old gateway address isn't removed. Note this also happens without changing the entire subnet, but is more subtle as shown in the original description. [regression potential] this affects how networkd handles routes, so has the potential to leave a system with partial or incorrect networking, or no networking at all. Any regression would most likely occur during networkd (re)start or during renewal of a DHCP lease, or when an interface is brought up. [other info] original description: --- Netplan config: network: version: 2 renderer: networkd ethernets: eno4: dhcp4: no eno1np0: dhcp4: no addresses: - 172.16.0.2/24 bridges: br0: dhcp4: yes interfaces: - eno4 On initial boot, machine got 10.0.15.109 IP address: May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 10.0.15.109/23 via 10.0.15.253 At one point, DHCP server reserver this IP address and client eventually picked up new IP address: May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address 10.0.15.128/23 via 10.0.15.253 This resulted in IP addresses: # ip -o a 1: loinet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: loinet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\ valid_lft forever preferred_lft forever 2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \ valid_lft forever preferred_lft forever 6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\ valid_lft 503sec preferred_lft 503sec 6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \ valid_lft forever preferred_lft forever So far, everything is fine. But, the routes on the machine are bogus: # ip r default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100 default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100 10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100 172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2 routes with src 10.0.15.109 should have been removed when lease was renewed. I'm not sure if this is a bug in netplan or systemd. This is 18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1831787/+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 1668771] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1668771 Title: [SRU] systemd-resolved negative caching for extended period of time Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Committed Bug description: [Impact] * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the result for very long (infinity?). I have to restart systemd- resolved to have the negative caching purged. * After SERVFAIL DNS server issue has been resolved, chromium/firefox still returns DNS error despite host can correctly resolve the name. [Test Case] * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s (See 201d995), however, there are several use cases on which this condition is not acceptable (See #5552 comments) and the only workaround would be to disable cache entirely or flush it , which isn't optimal. * Configure /etc/systemd/resolved.conf as follows: Cache=yes (default) * Restart systemd-resolved (systemctl restart systemd- resolved.service) * Run a host/getent command against a entry that will return SERVFAIL and check the journalctl output to see that the reply gets served from cache. root@systemd-disco:/home/ubuntu# host www.no-record.cl Host www.montemar.cl not found: 2(SERVFAIL) root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 UTC. -- Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for on scope dns on ens3/* now complete with Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet with id 61042 on interface 1/AF_INET. Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 6222. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query packet for id 53580 Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for www.no-record.cl IN A. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache hit for www.no-record.cl IN A Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < www.no-record.cl IN A> on scope dns on ens3/* now complete with scope dns on ens3/. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP for transaction 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet with id 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming packet on transaction 22382 (rcode=SERVFAIL). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: SERVFAIL Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative entry for: www.metaklass.org IN A, cache mode set to no-negative Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for on scope dns on ens3/ now complete with from network (unsigned). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet with id 31060 on interface 1/AF_INET. The following patch https://github.com/systemd/systemd/pull/13047 implements the required changes. [Other Info] Note that systemd in Eoan is being upgraded to upstream 242, so I am not adding this to Eoan now, as I don't want to disturb the merge. If needed after the merge, I'll add to Eoan. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1668771/+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 1849658] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1847896] Autopkgtest regression report (systemd/242-7ubuntu3.2)
All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1835738] Autopkgtest regression report (python3.6/3.6.9-1~18.04)
All autopkgtests for the newly accepted python3.6 (3.6.9-1~18.04) for bionic have finished running. The following regressions have been reported in tests triggered by the package: pybigwig/0.3.2-1ubuntu5 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#python3.6 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1835738 Title: SRU: Update Python interpreter to 3.6.9 and 3.7.5 Status in python3-defaults package in Ubuntu: New Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python3-defaults source package in Bionic: New Status in python3-stdlib-extensions source package in Bionic: New Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in python3-defaults source package in Disco: New Status in python3-stdlib-extensions source package in Disco: Fix Released Status in python3.7 source package in Disco: New Status in python3-defaults source package in Eoan: New Status in python3-stdlib-extensions source package in Eoan: Fix Released Status in python3.7 source package in Eoan: Fix Committed Bug description: Update Python interpreter to 3.6.9 and 3.7.5. As done with earlier subminor upstream releases (LP: #1822993). SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the 3.6.9 release. python3-stdlib-extensions also updates the modules to the 3.6.9 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1848200] Autopkgtest regression report (gdb/8.1-0ubuntu3.2)
All autopkgtests for the newly accepted gdb (8.1-0ubuntu3.2) for bionic have
finished running.
The following regressions have been reported in tests triggered by the package:
apport/2.20.9-0ubuntu7.8 (i386, amd64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#gdb
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1848200
Title:
gdb not stopping on breakpoint in a 32-bit program
Status in gdb package in Ubuntu:
Invalid
Status in gdb source package in Bionic:
Fix Committed
Status in gdb source package in Disco:
Invalid
Status in gdb source package in Eoan:
Invalid
Status in gdb source package in Focal:
Invalid
Bug description:
[Impact]
After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
on breakpoint when running a 32-bit application (on 64-bit Ubuntu).
[Test Case]
This can be reproduced with a simple “hello world” program:
$ cat hello.c
#include
int main()
{
// printf() displays the string inside quotation
printf("Hello, World!");
return 0;
}
$ gcc -ggdb -m32 hello.c
$ gdb a.out
(gdb) b hello.c:5
Breakpoint 1 at 0x536: file hello.c, line 5.
(gdb) run
Starting program: /home/user/sandbox/a.out
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
--- (and not stopping nor outputting the text…) ---
[Regression Risk]
Test case ran on arm64 and regression tested using the above test case on
amd64, i386 and s390x.
This regression was fixed on the upstream gdb-8.1 branch within a few
weeks of the breakage back in May 2018. Since then there have been no
other fixes in this area on that branch, implying this fixed the issue
and there were no further regressions discovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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 1845317] Autopkgtest regression report (linux-gcp-5.3/5.3.0-1008.9~18.04.1)
All autopkgtests for the newly accepted linux-gcp-5.3 (5.3.0-1008.9~18.04.1) for bionic have finished running. The following regressions have been reported in tests triggered by the package: linux-gcp-5.3/unknown (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#linux-gcp-5.3 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1845317 Title: Add new pci-id's for CML-S, ICL Status in libdrm package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux-oem-osp1 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Fix Released Status in libdrm source package in Bionic: New Status in linux source package in Bionic: Won't Fix Status in linux-oem-osp1 source package in Bionic: Fix Released Status in mesa source package in Bionic: Fix Released Bug description: [Impact] Comet Lake (CML) is basically same gen9 GPU as Sky Lake (SKL) (as is KBL, CFL, WHL). There are new CML-S desktop cpu's on the way, and they add three new pci-id's that need to be added across the stack in order to use the GPU properly. There's also one ICL pci-id which was added recently (not in 5.3). [Test case] The proper way to test is to have an actual machine and boot it up with the updated stack, but since these are just pci-id's with no regression potential on older hw, it should be fine to just accept them. [Regression potential] None, just adds new pci-id's to allow the new GPUs to load the proper drivers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1845317/+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 1852754] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1852754 Title: networkd does not complete interface configuration if Link MTUBytes is set Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] any regressions would likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1852754/+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 1849658] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1832672] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1832672 Title: systemd-resolve not ignoring comments in /etc/hosts Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] resolved does not ignore comments properly in /etc/hosts [test case] see original description below [regression potential] as this modifies resolved parsing of /etc/hosts, regressions would likely be in hostname lookups from hosts in /etc/hosts, or failure(s) to parse /etc/hosts correctly. [other info] original description: --- $ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 $ LANG=C apt-cache policy systemd systemd: Installed: 237-3ubuntu10.22 Candidate: 237-3ubuntu10.22 Version table: *** 237-3ubuntu10.22 500 500 http://ch.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.19 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages $ head -1 /etc/hosts 127.0.2.1 foo # bar $ /usr/bin/systemd-resolve -4 bar expected -- bar: resolve call failed: 'bar' not found What happened instead - bar: 127.0.2.1 HOSTS(5) > Text from a "#" character until the end of the line is a comment, and is ignored. This is fixed in upstream: https://github.com/systemd/systemd/issues/10779 https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656 Please backport to current LTS version. I accidentally connected to wrong systems because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1832672/+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 1805183] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade
[Touch-packages] [Bug 1796501] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1843381] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules
[Touch-packages] [Bug 1840640] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic
have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64)
dovecot/1:2.2.33.2-1ubuntu4.5 (armhf)
umockdev/0.11.1-1 (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#systemd
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Fix Committed
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
nspawn instructions:
sudo apt install debootstrap systemd-container
sudo -i
debootstrap --arch=armhf bionic ~/bionic-tree/
systemd-nspawn -D ~/bionic-tree/
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include
#include
#include
#include
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+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 1849733] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1850704] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1850704 Title: networkd doesn't set MTUBytes if interface is already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] if a networkd .network file specifies a [Link] section with MTUBytes=XXX set, networkd will only apply that mtu if the interface is down when networkd starts; if the interface is already up, the mtu won't be applied. [test case] on a bionic system, create a .network file like: [Match] Name=ens8 [Link] MTUBytes= then, reboot. The interface should be set correctly with that mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff now, manually change the interface back to 1500 mtu, and restart networkd, then recheck the mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo ip l set mtu 1500 dev ens8 $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo systemctl restart systemd-networkd $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff [regression potential] low, but any regression would likely involve failure to correctly set the configured mtu. this is needed only in bionic, it's fixed in disco and later already. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1850704/+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 1783994] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] on systems with mmc device installed, systemd-gpt-auto-generator fails. [test case] on a system with mmc device installed, run systemd-gpt-auto-generator and check log for: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error [regression potential] as this is related to boot, regressions might occur at boot, or while modifying or configuring a boot loader. [other info] original description: --- If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1783994/+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 1843381] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019
[Touch-packages] [Bug 1783994] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] on systems with mmc device installed, systemd-gpt-auto-generator fails. [test case] on a system with mmc device installed, run systemd-gpt-auto-generator and check log for: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error [regression potential] as this is related to boot, regressions might occur at boot, or while modifying or configuring a boot loader. [other info] original description: --- If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1783994/+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 1796501] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1849658] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1832672] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1832672 Title: systemd-resolve not ignoring comments in /etc/hosts Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] resolved does not ignore comments properly in /etc/hosts [test case] see original description below [regression potential] as this modifies resolved parsing of /etc/hosts, regressions would likely be in hostname lookups from hosts in /etc/hosts, or failure(s) to parse /etc/hosts correctly. [other info] original description: --- $ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 $ LANG=C apt-cache policy systemd systemd: Installed: 237-3ubuntu10.22 Candidate: 237-3ubuntu10.22 Version table: *** 237-3ubuntu10.22 500 500 http://ch.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.19 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages $ head -1 /etc/hosts 127.0.2.1 foo # bar $ /usr/bin/systemd-resolve -4 bar expected -- bar: resolve call failed: 'bar' not found What happened instead - bar: 127.0.2.1 HOSTS(5) > Text from a "#" character until the end of the line is a comment, and is ignored. This is fixed in upstream: https://github.com/systemd/systemd/issues/10779 https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656 Please backport to current LTS version. I accidentally connected to wrong systems because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1832672/+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 1805183] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade log present (probably fresh install) To manage
[Touch-packages] [Bug 1840640] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic
have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
linux/unknown (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#systemd
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Fix Committed
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
nspawn instructions:
sudo apt install debootstrap systemd-container
sudo -i
debootstrap --arch=armhf bionic ~/bionic-tree/
systemd-nspawn -D ~/bionic-tree/
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include
#include
#include
#include
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+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 1849733] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1850704] Autopkgtest regression report (systemd/237-3ubuntu10.32)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.32) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el) linux/unknown (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1850704 Title: networkd doesn't set MTUBytes if interface is already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] if a networkd .network file specifies a [Link] section with MTUBytes=XXX set, networkd will only apply that mtu if the interface is down when networkd starts; if the interface is already up, the mtu won't be applied. [test case] on a bionic system, create a .network file like: [Match] Name=ens8 [Link] MTUBytes= then, reboot. The interface should be set correctly with that mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff now, manually change the interface back to 1500 mtu, and restart networkd, then recheck the mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo ip l set mtu 1500 dev ens8 $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo systemctl restart systemd-networkd $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff [regression potential] low, but any regression would likely involve failure to correctly set the configured mtu. this is needed only in bionic, it's fixed in disco and later already. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1850704/+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 1844853] Autopkgtest regression report (glib2.0/2.48.2-0ubuntu4.5)
All autopkgtests for the newly accepted glib2.0 (2.48.2-0ubuntu4.5) for xenial
have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.28.2-1ubuntu1~16.04.3 (s390x)
dbus-test-runner/15.04.0+15.10.20151002-0ubuntu1 (arm64)
libreoffice/1:5.1.6~rc2-0ubuntu1~xenial10 (i386)
libglib-object-introspection-perl/0.040-2 (armhf)
network-manager/1.2.6-0ubuntu0.16.04.3 (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#glib2.0
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1844853
Title:
IBus no longer works in Qt applications after upgrade
Status in GLib:
Fix Released
Status in ibus:
Fix Released
Status in glib2.0 package in Ubuntu:
Fix Committed
Status in ibus package in Ubuntu:
Fix Released
Status in glib2.0 source package in Xenial:
Fix Committed
Status in glib2.0 source package in Bionic:
Fix Committed
Status in glib2.0 source package in Disco:
Fix Committed
Status in glib2.0 source package in Eoan:
Fix Committed
Status in glib2.0 source package in Focal:
Fix Committed
Status in ibus source package in Focal:
Fix Released
Status in glib2.0 package in Debian:
Fix Released
Bug description:
[Impact]
IBus was broken for Qt applications as a regression due to the fix of
CVE-2019-14822. As a result the IBus patch was disabled temporarily,
which fixed IBus from a usability POV.
The real fix has been made in glib2.0, and the updates in -proposed
will allow the IBus patch to be re-enabled.
[Test Case]
* On a standard Ubuntu {eoan,disco,bionic,xenial} installation
- Upgrade the glib2.0 packages from
{eoan,disco,bionic,xenial}-proposed
- Upgrade the ibus packages from
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
- Install some IBus input method, e.g. ibus-libpinyin
- Install some Qt application, e.g. Kate
* Relogin (maybe reboot)
* Add the input method to the input sources
* Open the Qt app and try to input something using the IBus IM
=> Find that the transliteration works as expected
[Regression Potential]
The applicable patches origin from glib upstream:
https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
Consequently the changes have been reviewed by the glib maintainer, but also
tested by the IBus maintainer, by me (gunnarhj), and - of course - the author
Simon McVittie. The changes have been in Debian unstable since 2019-10-30.
[Original description]
Kubuntu Release 18.04.3 LTS
Expected behavior:
ibus continues working as before after applying security update
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.
Observed behavior:
ibus is not usable anymore in Qt applications.
After updating ibus and the related packages ibus-gtk, ibus-gtk3,
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using
shift-space no longer changes the selected input method and even when i switch
to the mozc input method in a gtk application, i can not use it in any Qt
applications.
When starting qtconfig in a terminal, I also get the following message:
Bus::open: Connect ibus failed!
IBusInputContext::createInputContext: no connection to ibus-daemon
This bug was not present in version 1.5.17-3ubuntu5 and I also
confirmed that downgrading the packages to version 1.5.17-3ubuntu4
restores ibus functionality in Qt applications.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ibus 1.5.17-3ubuntu5.1
ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-30-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: KDE
Date: Sat Sep 21 07:58:56 2019
InstallationDate: Installed on 2019-06-28 (84 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64
(20190210)
SourcePackage: ibus
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1844853] Autopkgtest regression report (glib2.0/2.60.4-0ubuntu0.19.04.2)
All autopkgtests for the newly accepted glib2.0 (2.60.4-0ubuntu0.19.04.2) for
disco have finished running.
The following regressions have been reported in tests triggered by the package:
apport/2.20.10-0ubuntu27.3 (i386, amd64)
awesome/4.3-4 (armhf)
graphviz/unknown (armhf)
vlc/unknown (armhf)
systemd/240-6ubuntu5.7 (i386, amd64)
umockdev/0.12.1-2 (amd64)
udisks2/2.8.2-1 (arm64)
gtk+3.0/3.24.8-1ubuntu1 (armhf)
glib2.0/2.60.4-0ubuntu0.19.04.2 (i386)
sbd/1.3.1-4 (i386)
firefox/70.0.1+build1-0ubuntu0.19.04.1 (armhf)
lazarus/unknown (armhf)
dbus-test-runner/15.04.0+19.04.20190115-0ubuntu1 (ppc64el)
gvfs/1.40.1-1ubuntu0.1 (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#glib2.0
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1844853
Title:
IBus no longer works in Qt applications after upgrade
Status in GLib:
Fix Released
Status in ibus:
Fix Released
Status in glib2.0 package in Ubuntu:
Fix Committed
Status in ibus package in Ubuntu:
Fix Released
Status in glib2.0 source package in Xenial:
Fix Committed
Status in glib2.0 source package in Bionic:
Fix Committed
Status in glib2.0 source package in Disco:
Fix Committed
Status in glib2.0 source package in Eoan:
Fix Committed
Status in glib2.0 source package in Focal:
Fix Committed
Status in ibus source package in Focal:
Fix Released
Status in glib2.0 package in Debian:
Fix Released
Bug description:
[Impact]
IBus was broken for Qt applications as a regression due to the fix of
CVE-2019-14822. As a result the IBus patch was disabled temporarily,
which fixed IBus from a usability POV.
The real fix has been made in glib2.0, and the updates in -proposed
will allow the IBus patch to be re-enabled.
[Test Case]
* On a standard Ubuntu {eoan,disco,bionic,xenial} installation
- Upgrade the glib2.0 packages from
{eoan,disco,bionic,xenial}-proposed
- Upgrade the ibus packages from
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
- Install some IBus input method, e.g. ibus-libpinyin
- Install some Qt application, e.g. Kate
* Relogin (maybe reboot)
* Add the input method to the input sources
* Open the Qt app and try to input something using the IBus IM
=> Find that the transliteration works as expected
[Regression Potential]
The applicable patches origin from glib upstream:
https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
Consequently the changes have been reviewed by the glib maintainer, but also
tested by the IBus maintainer, by me (gunnarhj), and - of course - the author
Simon McVittie. The changes have been in Debian unstable since 2019-10-30.
[Original description]
Kubuntu Release 18.04.3 LTS
Expected behavior:
ibus continues working as before after applying security update
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.
Observed behavior:
ibus is not usable anymore in Qt applications.
After updating ibus and the related packages ibus-gtk, ibus-gtk3,
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using
shift-space no longer changes the selected input method and even when i switch
to the mozc input method in a gtk application, i can not use it in any Qt
applications.
When starting qtconfig in a terminal, I also get the following message:
Bus::open: Connect ibus failed!
IBusInputContext::createInputContext: no connection to ibus-daemon
This bug was not present in version 1.5.17-3ubuntu5 and I also
confirmed that downgrading the packages to version 1.5.17-3ubuntu4
restores ibus functionality in Qt applications.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ibus 1.5.17-3ubuntu5.1
ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-30-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: KDE
Date: Sat Sep 21 07:58:56 2019
InstallationDate: Installed on 2019-06-28 (84 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64
(20190210)
SourcePackage: ibus
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1846821] Autopkgtest regression report (qtbase-opensource-src/5.9.5+dfsg-0ubuntu2.4)
All autopkgtests for the newly accepted qtbase-opensource-src (5.9.5+dfsg-0ubuntu2.4) for bionic have finished running. The following regressions have been reported in tests triggered by the package: kcoreaddons/unknown (armhf) killbots/unknown (armhf) kfind/unknown (armhf) libkf5mailimporter/unknown (armhf) kcrash/5.44.0-0ubuntu1 (armhf) khtml/5.44.0-0ubuntu1 (armhf) pinentry/1.1.0-1 (amd64) ksystemlog/4:17.12.3-0ubuntu1 (armhf) kdepim-runtime/4:17.12.3-0ubuntu2 (armhf) kf5-messagelib/4:17.12.3-0ubuntu3 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#qtbase-opensource-src [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1846821 Title: Qt print dialog has wrong default page size Status in qtbase-opensource-src package in Ubuntu: Fix Released Status in qtbase-opensource-src source package in Bionic: Fix Committed Bug description: Please backport Qt patch 213677 to qtbase-opensource-src https://codereview.qt-project.org/c/qt/qtbase/+/213677 [Impact] In Qt5 applications, print dialog (Printer Properties) always defaults to A4 paper size, even when Letter is set as a default in all system and KDE preferences. After changing manually, Letter-size pages print correctly, but the setting does not stick. This impacts users of Qt applications who print things and live in countries where ISO 216 is not default, most notably the United States. [Test Case] 1) Use system settings (KDE preferences, gnome-control-center or system-config-printer) to set the printer size to Letter. 2) Open any Qt application (e.g. KWrite or Falkon). 3) Open a print dialog. 4) Behavior expected: Print dialog would default to Letter paper size and not A4. [Regression Potential] Two possibilities for regressions that I can imagine are: - crashes because something is not defined; - wrong default paper size (A4 wanted but CUPS returns something else). [Additional Information] The issue also affects other print settings, e.g. margins, though the aforementioned patch does not deal with these. A similar issue regarding the duplex setting was reported as Launchpad bug 1776173, and subsequently fixed, but other print settings continue to cause problems. Software versions: lsb_release: Ubuntu 18.04.3 LTS libqt5core5a: 5.9.5+dfsg-0ubuntu2.3 Kernel: 5.0.0-25-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1846821/+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 1835738] Autopkgtest regression report (python3.7/3.7.5-2~19.10)
All autopkgtests for the newly accepted python3.7 (3.7.5-2~19.10) for eoan have finished running. The following regressions have been reported in tests triggered by the package: libreoffice/1:6.3.3-0ubuntu0.19.10.1 (s390x) virtualbox/6.0.14-dfsg-1 (amd64) ros-ros-comm/1.14.3+ds1-5build2 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#python3.7 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1835738 Title: SRU: Update Python interpreter to 3.6.9 and 3.7.5 Status in python3-defaults package in Ubuntu: New Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python3-defaults source package in Bionic: New Status in python3-stdlib-extensions source package in Bionic: Fix Released Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in python3-defaults source package in Disco: New Status in python3-stdlib-extensions source package in Disco: Fix Released Status in python3.7 source package in Disco: New Status in python3-defaults source package in Eoan: New Status in python3-stdlib-extensions source package in Eoan: Fix Released Status in python3.7 source package in Eoan: Fix Committed Bug description: Update Python interpreter to 3.6.9 and 3.7.5. As done with earlier subminor upstream releases (LP: #1822993). SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the 3.6.9 release. python3-stdlib-extensions also updates the modules to the 3.6.9 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1848202] Autopkgtest regression report (glib2.0/2.62.2-2~ubuntu19.10.1)
All autopkgtests for the newly accepted glib2.0 (2.62.2-2~ubuntu19.10.1) for eoan have finished running. The following regressions have been reported in tests triggered by the package: indicator-session/17.3.20+19.10.20190921-0ubuntu1 (arm64) sbd/1.4.0-18-g5e3283c-1ubuntu1 (i386) cairo/unknown (armhf) netplan.io/0.98-0ubuntu1 (ppc64el) apport/2.20.11-0ubuntu8.2 (amd64) snapd-glib/unknown (armhf) firefox/70.0.1+build1-0ubuntu0.19.10.1 (armhf) bumblebee/unknown (armhf) glib2.0/2.62.2-2~ubuntu19.10.1 (i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#glib2.0 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1848202 Title: Use after free in gdbus leads to eds segfaults Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in glib2.0 source package in Eoan: Fix Committed Bug description: [ Description ] The Ubuntu Error Tracker has been receiving reports about a problem regarding evolution-data-server. This problem was most recently seen with package version 3.34.1-1, the problem page at https://errors.ubuntu.com/problem/b1f62616406e36e521fd1fb1d2be4ac2fe9a2cda 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/. [ Fix ] This bug was fixed upstream in 2.62.2 (see the links below). That update is being issues to eoan. [ QA ] Under https://wiki.ubuntu.com/StableReleaseUpdates/GNOME, we don't need to explicitly test that this bug is fixed. Nevertheless, to verify this bug please give the desktop a good workout. Ideally install the SRU and use your machine as you would normally for a variety of tasks. Make sure there are no regressions. [ Regression potential ] 1) The changes involve mutexes and stuff, which is error prone. 2) It's GLib, a core library, so any bad regressions will be really serious for the desktop as a whole. To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/1848202/+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 1844853] Autopkgtest regression report (glib2.0/2.56.4-0ubuntu0.18.04.5)
All autopkgtests for the newly accepted glib2.0 (2.56.4-0ubuntu0.18.04.5) for
bionic have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64)
cairo/unknown (armhf)
firefox/70.0.1+build1-0ubuntu0.18.04.1 (armhf)
pinentry/1.1.0-1 (amd64)
policykit-1/unknown (armhf)
systemd/237-3ubuntu10.31 (s390x)
cmake-extras/1.3+17.04.20170310-1ubuntu4 (armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#glib2.0
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1844853
Title:
IBus no longer works in Qt applications after upgrade
Status in GLib:
Fix Released
Status in ibus:
Fix Released
Status in glib2.0 package in Ubuntu:
Fix Committed
Status in ibus package in Ubuntu:
Fix Released
Status in glib2.0 source package in Xenial:
In Progress
Status in glib2.0 source package in Bionic:
Fix Committed
Status in glib2.0 source package in Disco:
In Progress
Status in glib2.0 source package in Eoan:
Fix Committed
Status in glib2.0 source package in Focal:
Fix Committed
Status in ibus source package in Focal:
Fix Released
Status in glib2.0 package in Debian:
Fix Released
Bug description:
[Impact]
IBus was broken for Qt applications as a regression due to the fix of
CVE-2019-14822. As a result the IBus patch was disabled temporarily,
which fixed IBus from a usability POV.
The real fix has been made in glib2.0, and the updates in -proposed
will allow the IBus patch to be re-enabled.
[Test Case]
* On a standard Ubuntu {eoan,disco,bionic,xenial} installation
- Upgrade the glib2.0 packages from
{eoan,disco,bionic,xenial}-proposed
- Upgrade the ibus packages from
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
- Install some IBus input method, e.g. ibus-libpinyin
- Install some Qt application, e.g. Kate
* Relogin (maybe reboot)
* Add the input method to the input sources
* Open the Qt app and try to input something using the IBus IM
=> Find that the transliteration works as expected
[Regression Potential]
The applicable patches origin from glib upstream:
https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
Consequently the changes have been reviewed by the glib maintainer, but also
tested by the IBus maintainer, by me (gunnarhj), and - of course - the author
Simon McVittie. The changes have been in Debian unstable since 2019-10-30.
[Original description]
Kubuntu Release 18.04.3 LTS
Expected behavior:
ibus continues working as before after applying security update
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.
Observed behavior:
ibus is not usable anymore in Qt applications.
After updating ibus and the related packages ibus-gtk, ibus-gtk3,
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using
shift-space no longer changes the selected input method and even when i switch
to the mozc input method in a gtk application, i can not use it in any Qt
applications.
When starting qtconfig in a terminal, I also get the following message:
Bus::open: Connect ibus failed!
IBusInputContext::createInputContext: no connection to ibus-daemon
This bug was not present in version 1.5.17-3ubuntu5 and I also
confirmed that downgrading the packages to version 1.5.17-3ubuntu4
restores ibus functionality in Qt applications.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ibus 1.5.17-3ubuntu5.1
ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-30-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: KDE
Date: Sat Sep 21 07:58:56 2019
InstallationDate: Installed on 2019-06-28 (84 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64
(20190210)
SourcePackage: ibus
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1850932] Autopkgtest regression report (glib2.0/2.62.2-2~ubuntu19.10.1)
All autopkgtests for the newly accepted glib2.0 (2.62.2-2~ubuntu19.10.1) for eoan have finished running. The following regressions have been reported in tests triggered by the package: indicator-session/17.3.20+19.10.20190921-0ubuntu1 (arm64) sbd/1.4.0-18-g5e3283c-1ubuntu1 (i386) cairo/unknown (armhf) netplan.io/0.98-0ubuntu1 (ppc64el) apport/2.20.11-0ubuntu8.2 (amd64) snapd-glib/unknown (armhf) firefox/70.0.1+build1-0ubuntu0.19.10.1 (armhf) bumblebee/unknown (armhf) glib2.0/2.62.2-2~ubuntu19.10.1 (i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#glib2.0 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1850932 Title: [SRU] Backport 2.62.2-2 Status in glib2.0 package in Ubuntu: Fix Released Status in glib2.0 source package in Eoan: Fix Committed Bug description: [ Description ] I'm creating this bug report to have a place to describe the proposed backport of glib2.0 2.62.2-2 from focal. The main purpose of this backport (as opposed to -1) is to fix bug #1844853. But there are several other changes. There are many cherry-picks to improve the testsuite's reliability. At the time of upload they weren't in the stable branch, but now they almost all are. These commits can be considered to be tested under https://wiki.ubuntu.com/StableReleaseUpdates/GNOME The two that are not are: commit 2b1e706b2f0007982f4fe6a70734d4490e4093a3 Author: Simon McVittie Date: Tue Oct 29 16:27:53 2019 + gdbus-server-auth test: Create temporary directory for Unix socket This avoids failure to listen on the given address on non-Linux Unix kernels, where abstract sockets do not exist and so unix:tmpdir is equivalent to unix:dir. To avoid bugs like this one recurring, run most of these tests using the unix:dir address type, where Linux is equivalent to other Unix kernels; just do one unix:tmpdir test, to check that we still interoperate with libdbus when using abstract sockets on Linux. Resolves: GNOME/glib#1920 Fixes: 9f962ebe "Add a test for GDBusServer authentication" Signed-off-by: Simon McVittie commit 9f962ebeac1d67223579ad0d261c4c8215f7c427 Author: Simon McVittie Date: Fri Oct 11 19:02:55 2019 +0100 Add a test for GDBusServer authentication In particular, if libbdus is available, we test interoperability with a libdbus client: see GNOME/glib#1831. Because that issue describes a race condition, we do each test repeatedly to try to hit the failing case. Signed-off-by: Simon McVittie which are both testsuite fixes. There are some additional non-upstream changes: * d/p/debian/mimeapps-test-Mark-as-flaky.patch: Drop patch, hopefully no longer needed with #941550 fixed * d/p/debian/taptestrunner-Stop-looking-like-an-executable-script.patch: Make taptestrunner non-executable to avoid a Lintian warning the former is again a testsuite fix. The latter is a fix to the test runner, which is relevant for the installed tests (run via autopkgtest) but not otherwise. [ QA ] The testsuite fixes will verify themselves during the build and autopkgtest. [ Regression potential ] all test fixes> Build failures or autopkgtest failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1850932/+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 1844853] Autopkgtest regression report (glib2.0/2.62.2-2~ubuntu19.10.1)
All autopkgtests for the newly accepted glib2.0 (2.62.2-2~ubuntu19.10.1) for
eoan have finished running.
The following regressions have been reported in tests triggered by the package:
indicator-session/17.3.20+19.10.20190921-0ubuntu1 (arm64)
sbd/1.4.0-18-g5e3283c-1ubuntu1 (i386)
cairo/unknown (armhf)
netplan.io/0.98-0ubuntu1 (ppc64el)
apport/2.20.11-0ubuntu8.2 (amd64)
snapd-glib/unknown (armhf)
firefox/70.0.1+build1-0ubuntu0.19.10.1 (armhf)
bumblebee/unknown (armhf)
glib2.0/2.62.2-2~ubuntu19.10.1 (i386)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#glib2.0
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1844853
Title:
IBus no longer works in Qt applications after upgrade
Status in GLib:
Fix Released
Status in ibus:
Fix Released
Status in glib2.0 package in Ubuntu:
Fix Committed
Status in ibus package in Ubuntu:
Fix Released
Status in glib2.0 source package in Xenial:
In Progress
Status in glib2.0 source package in Bionic:
Fix Committed
Status in glib2.0 source package in Disco:
In Progress
Status in glib2.0 source package in Eoan:
Fix Committed
Status in glib2.0 source package in Focal:
Fix Committed
Status in ibus source package in Focal:
Fix Released
Status in glib2.0 package in Debian:
Fix Released
Bug description:
[Impact]
IBus was broken for Qt applications as a regression due to the fix of
CVE-2019-14822. As a result the IBus patch was disabled temporarily,
which fixed IBus from a usability POV.
The real fix has been made in glib2.0, and the updates in -proposed
will allow the IBus patch to be re-enabled.
[Test Case]
* On a standard Ubuntu {eoan,disco,bionic,xenial} installation
- Upgrade the glib2.0 packages from
{eoan,disco,bionic,xenial}-proposed
- Upgrade the ibus packages from
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
- Install some IBus input method, e.g. ibus-libpinyin
- Install some Qt application, e.g. Kate
* Relogin (maybe reboot)
* Add the input method to the input sources
* Open the Qt app and try to input something using the IBus IM
=> Find that the transliteration works as expected
[Regression Potential]
The applicable patches origin from glib upstream:
https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
Consequently the changes have been reviewed by the glib maintainer, but also
tested by the IBus maintainer, by me (gunnarhj), and - of course - the author
Simon McVittie. The changes have been in Debian unstable since 2019-10-30.
[Original description]
Kubuntu Release 18.04.3 LTS
Expected behavior:
ibus continues working as before after applying security update
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.
Observed behavior:
ibus is not usable anymore in Qt applications.
After updating ibus and the related packages ibus-gtk, ibus-gtk3,
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using
shift-space no longer changes the selected input method and even when i switch
to the mozc input method in a gtk application, i can not use it in any Qt
applications.
When starting qtconfig in a terminal, I also get the following message:
Bus::open: Connect ibus failed!
IBusInputContext::createInputContext: no connection to ibus-daemon
This bug was not present in version 1.5.17-3ubuntu5 and I also
confirmed that downgrading the packages to version 1.5.17-3ubuntu4
restores ibus functionality in Qt applications.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ibus 1.5.17-3ubuntu5.1
ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-30-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: KDE
Date: Sat Sep 21 07:58:56 2019
InstallationDate: Installed on 2019-06-28 (84 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64
(20190210)
SourcePackage: ibus
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1854981] Autopkgtest regression report (lvm2/2.02.176-4.1ubuntu4.2)
All autopkgtests for the newly accepted lvm2 (2.02.176-4.1ubuntu4.2) for disco
have finished running.
The following regressions have been reported in tests triggered by the package:
writeboost/unknown (armhf)
udisks2/unknown (armhf)
cinder/2:14.0.1-0ubuntu1 (i386, ppc64el, s390x, amd64, arm64, armhf)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#lvm2
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1854981
Title:
system doesn't properly boot as expected if /usr is on its own LV
Status in initramfs-tools package in Ubuntu:
Won't Fix
Status in lvm2 package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Xenial:
Won't Fix
Status in lvm2 source package in Xenial:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original Description]
Only the lv for root volume get activated, because of the grub
parameter that specifies/enforce it "root=/dev/mapper/ubuntu-vg-ubuntu
--lv"
http://man7.org/linux/man-pages/man7/bootparam.7.html
'root=...'
This argument tells the kernel what device is to be used as
the root filesystem while booting.
If one add a separate LV for /usr, the system will go straight to
initramfs prompt failling to mount /usr.
At initramfs prompt, we notice that 'lv-usr' status is 'NOT
available'.
Performing 'lvm vgchange -ay' at initramfs prompt workaround the
problem and allow one to successfully boot.
Adding 'debug' parameter, we clearly we see /root being detected and mounted:
initramfs.debug:
=> + mount -r -t ext4 /dev/mapper/ubuntu--vg-ubuntu--lv /root
=> + mountroot_status=0
+ [ ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ read_fstab_entry /usr
+ found=1
+ [ -f /root/etc/fstab ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS
[Touch-packages] [Bug 1855133] Autopkgtest regression report (python-stdlib-extensions/2.7.17-1~18.04)
All autopkgtests for the newly accepted python-stdlib-extensions (2.7.17-1~18.04) for bionic have finished running. The following regressions have been reported in tests triggered by the package: pyfai/0.15.0+dfsg1-1 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#python-stdlib-extensions [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1855133 Title: SRU: update python2.7 to the 2.7.17 release Status in python-stdlib-extensions package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python-stdlib-extensions source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python-stdlib-extensions source package in Eoan: Fix Committed Status in python2.7 source package in Eoan: Fix Committed Bug description: This is a proposal to backport the Python 2.7.17 release to bionic. - python2.7 - python-stdlib-extensions - python-defaults is not required, but could be used to trigger autopkg tests in the -proposed pocket. The package builds are prepared in https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+packages [Impact] Provide an upstream release for Python 2.7. [Regression Potential] There is regression potential, however with a test rebuild of the main portion of the archive no regressions were found. [Test Case] No regressions in the Python test suite, and no regressions in the test rebuild of the main component of the archive (all architectures) As a test, an archive rebuild for main was performed, and no regressions were found with this new package. The archive rebuild also contained updated versions of gcc-7, gcc-8, python-stdlib-extensions and python2.7. The GCC and Python packages should not infer with each other. [Validation] Analyze the build logs for regressions. The OpenStack packaging team is checking OpenStack against the built packages in -proposed. Summary of the test rebuilds: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-bionic.html https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-gcc7-bionic.html The first one is a reference build, the second one the test rebuild with the updated components. There are no additional regressions except for one Python test, which sometimes hangs on the buildds, sometimes passes (test_ttk_guionly). Will be disabled in a follow-up upload. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/1855133/+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 1854981] Autopkgtest regression report (lvm2/2.02.176-4.1ubuntu3.18.04.2)
All autopkgtests for the newly accepted lvm2 (2.02.176-4.1ubuntu3.18.04.2) for
bionic have finished running.
The following regressions have been reported in tests triggered by the package:
ganeti/2.16.0~rc2-1build1 (arm64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#lvm2
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1854981
Title:
system doesn't properly boot as expected if /usr is on its own LV
Status in initramfs-tools package in Ubuntu:
Won't Fix
Status in lvm2 package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Xenial:
Won't Fix
Status in lvm2 source package in Xenial:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original Description]
Only the lv for root volume get activated, because of the grub
parameter that specifies/enforce it "root=/dev/mapper/ubuntu-vg-ubuntu
--lv"
http://man7.org/linux/man-pages/man7/bootparam.7.html
'root=...'
This argument tells the kernel what device is to be used as
the root filesystem while booting.
If one add a separate LV for /usr, the system will go straight to
initramfs prompt failling to mount /usr.
At initramfs prompt, we notice that 'lv-usr' status is 'NOT
available'.
Performing 'lvm vgchange -ay' at initramfs prompt workaround the
problem and allow one to successfully boot.
Adding 'debug' parameter, we clearly we see /root being detected and mounted:
initramfs.debug:
=> + mount -r -t ext4 /dev/mapper/ubuntu--vg-ubuntu--lv /root
=> + mountroot_status=0
+ [ ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ read_fstab_entry /usr
+ found=1
+ [ -f /root/etc/fstab ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
+ [ / = /usr ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE
[Touch-packages] [Bug 1855133] Autopkgtest regression report (python2.7/2.7.17-1~18.04)
All autopkgtests for the newly accepted python2.7 (2.7.17-1~18.04) for bionic have finished running. The following regressions have been reported in tests triggered by the package: pdal/unknown (armhf) mercurial/4.5.3-1ubuntu2.1 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#python2.7 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1855133 Title: SRU: update python2.7 to the 2.7.17 release Status in python-stdlib-extensions package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python-stdlib-extensions source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python-stdlib-extensions source package in Eoan: Fix Committed Status in python2.7 source package in Eoan: Fix Committed Bug description: This is a proposal to backport the Python 2.7.17 release to bionic. - python2.7 - python-stdlib-extensions - python-defaults is not required, but could be used to trigger autopkg tests in the -proposed pocket. The package builds are prepared in https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+packages [Impact] Provide an upstream release for Python 2.7. [Regression Potential] There is regression potential, however with a test rebuild of the main portion of the archive no regressions were found. [Test Case] No regressions in the Python test suite, and no regressions in the test rebuild of the main component of the archive (all architectures) As a test, an archive rebuild for main was performed, and no regressions were found with this new package. The archive rebuild also contained updated versions of gcc-7, gcc-8, python-stdlib-extensions and python2.7. The GCC and Python packages should not infer with each other. [Validation] Analyze the build logs for regressions. The OpenStack packaging team is checking OpenStack against the built packages in -proposed. Summary of the test rebuilds: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-bionic.html https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-gcc7-bionic.html The first one is a reference build, the second one the test rebuild with the updated components. There are no additional regressions except for one Python test, which sometimes hangs on the buildds, sometimes passes (test_ttk_guionly). Will be disabled in a follow-up upload. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/1855133/+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 1808476] Autopkgtest regression report (python2.7/2.7.17-1~18.04)
All autopkgtests for the newly accepted python2.7 (2.7.17-1~18.04) for bionic have finished running. The following regressions have been reported in tests triggered by the package: pdal/unknown (armhf) mercurial/4.5.3-1ubuntu2.1 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#python2.7 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1808476 Title: Please bump libssl1.1 dependency to at least >= 1.1.1, as headers leak constants Status in python2.7 package in Ubuntu: Fix Released Status in python2.7 source package in Bionic: Fix Committed Status in python2.7 source package in Cosmic: Fix Released Status in python2.7 source package in Disco: Fix Released Bug description: [Impact] $ python -c 'import ssl; print(ssl.OP_NO_TLSv1_3)' Prints 0, for python2.7 built against 1.1.0 headers, yet prints 536870912 when built against 1.1.1 irrespective of the runtime libssl1.1 library version. This may yield confusion, especially since ssl.OPENSSL_VERSION reports runtime libssl version, not the version of the libssl headers. Such that, e.g. it looks like ssl module is running against 1.1.1, has OP_NO_TLSv1_3 option, yet cannot actually use it to disable TLSv1.3. Also vice versa, python2.7 build against 1.1.1 can be installed with 1.1.0 runtime library, and thus OP_NO_TLSv1_3 might be set, which is not understood by the runtime library. In libpython2.7-stdlib, please bump libssl1.1 version dep to "libssl1.1 (>= 1.1.1)" when building against libssl-dev >= 1.1.1. python3.x are not affected, as they started to exploit 1.1.1-only symbols/features, and thus already have an automatic dep on >= 1.1.1. [Test Case] Make sure the libssl1.1 build-dependency of python2.7 is at least 1.1.1. [Regression Potential] Potentially none, besides the usual regression potential of new rebuilds. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1808476/+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 1855009] Autopkgtest regression report (network-manager/1.20.4-2ubuntu2.1)
All autopkgtests for the newly accepted network-manager (1.20.4-2ubuntu2.1) for eoan have finished running. The following regressions have been reported in tests triggered by the package: netplan.io/0.98-0ubuntu1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1855009 Title: autopkgtests all fail on s390x Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager source package in Bionic: Fix Committed Status in network-manager source package in Disco: Fix Committed Status in network-manager source package in Eoan: Fix Committed Status in network-manager source package in Focal: Fix Released Bug description: [impact] all autopkgtests fail on s390x [test case] check autopkgtest logs, e.g. http://autopkgtest.ubuntu.com/packages/network-manager https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal/focal/s390x/n/network- manager/20191130_001946_a5512@/log.gz autopkgtest [00:19:32]: summary wpa-dhclient FAIL non-zero exit status 1 nm.pyFAIL non-zero exit status 1 killswitches-no-urfkill FAIL non-zero exit status 1 urfkill-integration FAIL non-zero exit status 1 [regression potential] this essentially skips all the autopkgtests for network-manager on s390x, so regressions could occur now or in the future due to lack of testing on s390x. However, all the tests already fail on s390x and have since xenial (or earlier), so there hasn't been any useful test coverage on s390x before; this doesn't change that. [other info] as mentioned in comment 2, wireless networking is specifically excluded on s390 systems: menuconfig WIRELESS bool "Wireless" depends on !S390 default y The 'wpa-dhclient' test is specific to wireless, and both 'killswitches-no-urfkill' and 'urfkill-integration' require rfkill which requires wireless, so none of those tests are valid on s390x, since it doesn't have any wireless support. However the 'nm.py' test does have some test cases that don't rely on wireless capability, but it would be much more intrusive to update the test to split out wired vs. wireless testing, and that might introduce test regressions on other archs. The use case for network-manager on s390x in general is questionable, since s390x has no wireless support and obviously is never 'mobile', which are 2 main reasons to use network-manager instead of systemd-networkd. Additionally, all tests are currently skipped on armhf due to the requirement for machine isolation (and armhf tests run in containers), so s390x is not the first arch to simply skip all network-manager autopkgtests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1855009/+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 1852489] Autopkgtest regression report (software-properties/0.96.24.32.12)
All autopkgtests for the newly accepted software-properties (0.96.24.32.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: livecd-rootfs/2.525.35 (arm64, ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#software-properties [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1852489 Title: [SRU] Enable support for Ussuri Cloud Archive Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Bionic: Fix Committed Status in software-properties source package in Focal: Fix Released Bug description: Please add support for: cloud-archive:ussuri cloud-archive:ussuri-proposed This will also need to be SRU'd back to bionic. [Impact] End users have to manually enable the ussuri cloud archive pockets. [Test case] sudo add-apt-repository cloud-archive:ussuri sudo add-apt-repository cloud-archive:ussuri-proposed [Regression potential] Limited - just a data item addition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852489/+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 1855009] Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.3)
All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.3) for bionic have finished running. The following regressions have been reported in tests triggered by the package: systemd/237-3ubuntu10.33 (ppc64el) systemd/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1855009 Title: autopkgtests all fail on s390x Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager source package in Bionic: Fix Committed Status in network-manager source package in Disco: Fix Committed Status in network-manager source package in Eoan: Fix Committed Status in network-manager source package in Focal: Fix Released Bug description: [impact] all autopkgtests fail on s390x [test case] check autopkgtest logs, e.g. http://autopkgtest.ubuntu.com/packages/network-manager https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal/focal/s390x/n/network- manager/20191130_001946_a5512@/log.gz autopkgtest [00:19:32]: summary wpa-dhclient FAIL non-zero exit status 1 nm.pyFAIL non-zero exit status 1 killswitches-no-urfkill FAIL non-zero exit status 1 urfkill-integration FAIL non-zero exit status 1 [regression potential] this essentially skips all the autopkgtests for network-manager on s390x, so regressions could occur now or in the future due to lack of testing on s390x. However, all the tests already fail on s390x and have since xenial (or earlier), so there hasn't been any useful test coverage on s390x before; this doesn't change that. [other info] as mentioned in comment 2, wireless networking is specifically excluded on s390 systems: menuconfig WIRELESS bool "Wireless" depends on !S390 default y The 'wpa-dhclient' test is specific to wireless, and both 'killswitches-no-urfkill' and 'urfkill-integration' require rfkill which requires wireless, so none of those tests are valid on s390x, since it doesn't have any wireless support. However the 'nm.py' test does have some test cases that don't rely on wireless capability, but it would be much more intrusive to update the test to split out wired vs. wireless testing, and that might introduce test regressions on other archs. The use case for network-manager on s390x in general is questionable, since s390x has no wireless support and obviously is never 'mobile', which are 2 main reasons to use network-manager instead of systemd-networkd. Additionally, all tests are currently skipped on armhf due to the requirement for machine isolation (and armhf tests run in containers), so s390x is not the first arch to simply skip all network-manager autopkgtests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1855009/+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 1855092] Autopkgtest regression report (pam/1.3.1-5ubuntu1.19.10.0)
All autopkgtests for the newly accepted pam (1.3.1-5ubuntu1.19.10.0) for eoan have finished running. The following regressions have been reported in tests triggered by the package: systemd/unknown (armhf) lxc/3.0.4-0ubuntu1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#pam [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1855092 Title: [SRU] Please set MOTD_SHOWN=pam when MOTD was shown Status in pam package in Ubuntu: Fix Released Status in pam source package in Eoan: Fix Committed Bug description: [Impact] * Users of containers may never see the MOTD of the container if they are always to the container's shell without PAM being involved. * MOTD contains important information about the system's health including the security updates to be installed thus it is desired to show MOTD in container shells, too. * The fix in update-motd is creating a snippet in /etc/profile.d which shows MOTD, but only if UPDATE_MOTD is not set, to avoid printing MOTD twice. [Test Case] * Log in to the system, where PAM prints the MOTD. * After seeing the MOTD observe MOTD_SHOWN set: $ echo $MOTD_SHOWN pam $ [Regression Potential] * The fix is simple thus it is unlikely to see any regression due to bad implementation. * The newly set environment variable may interact with existing software, but this variable seems to be not used: https://codesearch.debian.net/search?q=MOTD_SHOWN=1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1855092/+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 1855009] Autopkgtest regression report (network-manager/1.16.0-0ubuntu2.1)
All autopkgtests for the newly accepted network-manager (1.16.0-0ubuntu2.1) for disco have finished running. The following regressions have been reported in tests triggered by the package: systemd/unknown (armhf) network-manager/1.16.0-0ubuntu2.1 (ppc64el) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1855009 Title: autopkgtests all fail on s390x Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager source package in Bionic: Fix Committed Status in network-manager source package in Disco: Fix Committed Status in network-manager source package in Eoan: Fix Committed Status in network-manager source package in Focal: Fix Released Bug description: [impact] all autopkgtests fail on s390x [test case] check autopkgtest logs, e.g. http://autopkgtest.ubuntu.com/packages/network-manager https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal/focal/s390x/n/network- manager/20191130_001946_a5512@/log.gz autopkgtest [00:19:32]: summary wpa-dhclient FAIL non-zero exit status 1 nm.pyFAIL non-zero exit status 1 killswitches-no-urfkill FAIL non-zero exit status 1 urfkill-integration FAIL non-zero exit status 1 [regression potential] this essentially skips all the autopkgtests for network-manager on s390x, so regressions could occur now or in the future due to lack of testing on s390x. However, all the tests already fail on s390x and have since xenial (or earlier), so there hasn't been any useful test coverage on s390x before; this doesn't change that. [other info] as mentioned in comment 2, wireless networking is specifically excluded on s390 systems: menuconfig WIRELESS bool "Wireless" depends on !S390 default y The 'wpa-dhclient' test is specific to wireless, and both 'killswitches-no-urfkill' and 'urfkill-integration' require rfkill which requires wireless, so none of those tests are valid on s390x, since it doesn't have any wireless support. However the 'nm.py' test does have some test cases that don't rely on wireless capability, but it would be much more intrusive to update the test to split out wired vs. wireless testing, and that might introduce test regressions on other archs. The use case for network-manager on s390x in general is questionable, since s390x has no wireless support and obviously is never 'mobile', which are 2 main reasons to use network-manager instead of systemd-networkd. Additionally, all tests are currently skipped on armhf due to the requirement for machine isolation (and armhf tests run in containers), so s390x is not the first arch to simply skip all network-manager autopkgtests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1855009/+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 1855009] Autopkgtest regression report (network-manager/1.2.6-0ubuntu0.16.04.4)
All autopkgtests for the newly accepted network-manager (1.2.6-0ubuntu0.16.04.4) for xenial have finished running. The following regressions have been reported in tests triggered by the package: nplan/0.32~16.04.7 (i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1855009 Title: autopkgtests all fail on s390x Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager source package in Bionic: Fix Committed Status in network-manager source package in Disco: Fix Committed Status in network-manager source package in Eoan: Fix Committed Status in network-manager source package in Focal: Fix Released Bug description: [impact] all autopkgtests fail on s390x [test case] check autopkgtest logs, e.g. http://autopkgtest.ubuntu.com/packages/network-manager https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal/focal/s390x/n/network- manager/20191130_001946_a5512@/log.gz autopkgtest [00:19:32]: summary wpa-dhclient FAIL non-zero exit status 1 nm.pyFAIL non-zero exit status 1 killswitches-no-urfkill FAIL non-zero exit status 1 urfkill-integration FAIL non-zero exit status 1 [regression potential] this essentially skips all the autopkgtests for network-manager on s390x, so regressions could occur now or in the future due to lack of testing on s390x. However, all the tests already fail on s390x and have since xenial (or earlier), so there hasn't been any useful test coverage on s390x before; this doesn't change that. [other info] as mentioned in comment 2, wireless networking is specifically excluded on s390 systems: menuconfig WIRELESS bool "Wireless" depends on !S390 default y The 'wpa-dhclient' test is specific to wireless, and both 'killswitches-no-urfkill' and 'urfkill-integration' require rfkill which requires wireless, so none of those tests are valid on s390x, since it doesn't have any wireless support. However the 'nm.py' test does have some test cases that don't rely on wireless capability, but it would be much more intrusive to update the test to split out wired vs. wireless testing, and that might introduce test regressions on other archs. The use case for network-manager on s390x in general is questionable, since s390x has no wireless support and obviously is never 'mobile', which are 2 main reasons to use network-manager instead of systemd-networkd. Additionally, all tests are currently skipped on armhf due to the requirement for machine isolation (and armhf tests run in containers), so s390x is not the first arch to simply skip all network-manager autopkgtests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1855009/+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 1825946] Autopkgtest regression report (network-manager/1.2.6-0ubuntu0.16.04.4)
All autopkgtests for the newly accepted network-manager
(1.2.6-0ubuntu0.16.04.4) for xenial have finished running.
The following regressions have been reported in tests triggered by the package:
nplan/0.32~16.04.7 (i386)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#network-manager
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1825946
Title:
'nm' autopkgtest fails due to GI stderr output
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Xenial:
Fix Committed
Status in network-manager source package in Bionic:
Fix Released
Bug description:
[impact]
'nm' testcase contains:
from gi.repository import NetworkManager, NMClient, GLib
which generates output to stderr:
/tmp/autopkgtest.naU0ts/build.riU/src/debian/tests/nm:23: PyGIWarning:
NetworkManager was imported without specifying a version first. Use
gi.require_version('NetworkManager', '1.0') before import to ensure that the
right version gets loaded.
the gi.require_version call has already been added to cosmic and
disco.
[test case]
see http://autopkgtest.ubuntu.com/packages/network-manager bionic test
results.
[other info]
this only fails intermittently, but the failure is clearly not an
actual problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1825946/+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 1850267] Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.3)
All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.3) for bionic have finished running. The following regressions have been reported in tests triggered by the package: systemd/237-3ubuntu10.33 (ppc64el) systemd/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1850267 Title: autopkgtest 'nm' fails because it can't find dnsmasq Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: [impact] test 'nm' fails because dnsmasq-base isn't installed [test case] see test results http://autopkgtest.ubuntu.com/packages/network-manager/bionic/amd64 [regression potential] low, test fix only [other info] The d/t/control file 'nm' test section, for bionic, needs to include dnsmasq-base in its dep list. disco and later already include dnsmasq-base in test dep packages, and in xenial network-manager directly depends on dnsmasq-base. So this is needed only for bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1850267/+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 1855183] Autopkgtest regression report (network-manager/1.20.4-2ubuntu2.1)
All autopkgtests for the newly accepted network-manager (1.20.4-2ubuntu2.1) for eoan have finished running. The following regressions have been reported in tests triggered by the package: netplan.io/0.98-0ubuntu1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1855183 Title: autopkgtest fails on i386 because linux-headers-generic no longer built for i386 Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Eoan: Fix Committed Status in network-manager source package in Focal: Fix Released Bug description: [impact] the kernel is no longer built for i386, starting with Eoan. However some of the autopkgtests depend on linux-headers-generic, which isn't available for i386, so the test fails with bad dependency. [test case] check autopkgtest logs, e.g. http://autopkgtest.ubuntu.com/packages/network-manager/focal/i386 Broken autopkgtest-satdep:i386 Depends on linux-headers-generic:i386 < none @un H > Removing autopkgtest-satdep:i386 because I can't find linux-headers-generic:i386 [regression potential] test case fix only, regressions would involve more/continued test failure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1855183/+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 1843479] Autopkgtest regression report (binutils/2.33-2ubuntu1.1)
All autopkgtests for the newly accepted binutils (2.33-2ubuntu1.1) for eoan
have finished running.
The following regressions have been reported in tests triggered by the package:
glibc/2.30-0ubuntu2 (amd64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#binutils
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip in Ubuntu Eoan results in Exec format error on WSL1
Status in binutils:
Confirmed
Status in binutils package in Ubuntu:
Fix Released
Status in gzip package in Ubuntu:
In Progress
Status in binutils source package in Eoan:
Fix Committed
Bug description:
[Impact]
* Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
* The error occurs frequently in package updates and makes gzip inoperable
on WSL1
* The problem is caused by PT_LOAD offset pointing past the end of file and
the fix is fixing strip to not generate such ELF files and recompiling gzip
with the fixed strip.
[Test Case]
* Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v
size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
[ Regression Potential ]
* The binutils fix could cause binutils to generate invalid ELF files. The
fix is very small and isolated and has been tested and accepted by upstream,
which makes such problems unlikely.
* Bugs in the toolchain in general can make the rebuilt gzip show new
errors, but this generally applies to many SRUs and security updates. The
testing period in proposed should mitigate this risk.
[Originial Bug Text]
Summary:
Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
What I expect to happen:
gzip executes correctly on WSL1.
What happens instead:
gzip fails with an Exec format error.
Notes:
I suspect a change in how gzip is being built for Eoan is causing
issues with ELF parsing on the WSL1 translation layer. For example:
On Disco with gzip 1.9-3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
On Eoan with gzip 1.10-0ubuntu3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0,
stripped
Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
not believe this is an issue in 1.10 because this error does not occur
when building gzip from GNU project source on Ubuntu Eoan.
Justifications:
WSL1 will need to be patched in future Windows builds for this change
in ELF. However that patch will likely not be backported to older
builds of Windows, including Windows Enterprise/Server 2019.
To ensure Eoan can run on current and older builds of Windows Ubuntu
should consider looking at how it's building gzip and see if it can be
made to 'play nice' until WSL1 can be updated.
This was originally reported here:
https://github.com/microsoft/WSL/issues/4461
Details:
Description:Ubuntu Eoan Ermine (development branch)
Release:19.10
gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
*** 1.10-0ubuntu3 500
500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+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 1754671] Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.2)
All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: network-manager/1.10.6-2ubuntu1.2 (amd64, arm64, i386, ppc64el) systemd/237-3ubuntu10.31 (i386, ppc64el) netplan.io/0.98-0ubuntu1~18.04.1 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Confirmed Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+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 1790098] Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.2)
All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: network-manager/1.10.6-2ubuntu1.2 (amd64, arm64, i386, ppc64el) systemd/237-3ubuntu10.31 (i386, ppc64el) netplan.io/0.98-0ubuntu1~18.04.1 (arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#network-manager [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1790098 Title: vlan created on bond fails auto activation on updating parent network bond Status in Ubuntu on IBM z Systems: Won't Fix Status in network-manager package in Ubuntu: Won't Fix Status in network-manager source package in Bionic: Fix Committed Bug description: Auto activation of Vlan created over network-bond fails if bond is deactivated and reactivated. Contact Information = Abhiram Kulkarni(abhir...@in.ibm.com), Mandar Deshpande(manda...@in.ibm.com) ---uname output--- Linux S36MANDAR 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Created a network bond with static IP address (and no IPv6 address); active backup mode; ARP polling; single slave. 2. Created a VLAN using said network bond with static IPv4 address (and no IPv6 address). 3. Can ping from the appliance to a target on both links (the parent bond and the VLAN). 4. Switched to another slave for the created bond 5. Can still ping from the appliance to a target via the parent bond; however, cannot ping to the target via the VLAN. = Detailed steps: 1. Initial setup: root@S36MANDAR:~# nmcli c s NAMEUUID TYPE DEVICE enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093 ethernet enc1a80 enc8f00 2423add6-1464-3765-877c-a214dc497492 ethernet enc8f00 enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605 ethernet -- 2. Create Netwrok-bond with one slave: root@S36MANDAR:~# nmcli c add type bond con-name mybond1 ifname mybond1 ipv4.method disabled ipv6.method ignore Connection 'mybond1' (4b918a65-43a6-4ec3-b3c4-388ed52b116d) successfully added. root@S36MANDAR:~# nmcli con add type ethernet ifname enc1d40 master mybond1 Connection 'bond-slave-enc1d40' (cfe4b245-3dda-4f45-b7b4-6d40d144a02f) successfully added. root@S36MANDAR:~# nmcli con up bond-slave-enc1d40 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/18) root@S36MANDAR:~# nmcli c s NAMEUUID TYPE DEVICE bond-slave-enc1d40 cfe4b245-3dda-4f45-b7b4-6d40d144a02f ethernet enc1d40 enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093 ethernet enc1a80 enc8f00 2423add6-1464-3765-877c-a214dc497492 ethernet enc8f00 mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d bond mybond1 enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605 ethernet -- 3. Create vlan over mybond1: === root@S36MANDAR:~# nmcli con add type vlan con-name vlanbond.100 ifname vlanbond.100 dev mybond1 id 100 ipv4.method disabled ipv6.method ignore Connection 'vlanbond.100' (e054df42-97a0-492b-b2c9-b9571077493e) successfully added. root@S36MANDAR:~# nmcli c s NAMEUUID TYPE DEVICE bond-slave-enc1d40 cfe4b245-3dda-4f45-b7b4-6d40d144a02f ethernet enc1d40 enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093 ethernet enc1a80 enc8f00 2423add6-1464-3765-877c-a214dc497492 ethernet enc8f00 mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d bond mybond1 vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e vlan vlanbond.100 enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605 ethernet -- 4. Reactivate bond : = root@S36MANDAR:~# nmcli con up mybond1 Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/30) root@S36MANDAR:~# nmcli c s NAMEUUID TYPE DEVICE enc1a80
[Touch-packages] [Bug 1825946] Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.2)
All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.2) for
bionic have finished running.
The following regressions have been reported in tests triggered by the package:
network-manager/1.10.6-2ubuntu1.2 (amd64, arm64, i386, ppc64el)
systemd/237-3ubuntu10.31 (i386, ppc64el)
netplan.io/0.98-0ubuntu1~18.04.1 (arm64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#network-manager
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1825946
Title:
'nm' autopkgtest fails due to GI stderr output
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Xenial:
New
Status in network-manager source package in Bionic:
Fix Committed
Bug description:
[impact]
'nm' testcase contains:
from gi.repository import NetworkManager, NMClient, GLib
which generates output to stderr:
/tmp/autopkgtest.naU0ts/build.riU/src/debian/tests/nm:23: PyGIWarning:
NetworkManager was imported without specifying a version first. Use
gi.require_version('NetworkManager', '1.0') before import to ensure that the
right version gets loaded.
the gi.require_version call has already been added to cosmic and
disco.
[test case]
see http://autopkgtest.ubuntu.com/packages/network-manager bionic test
results.
[other info]
this only fails intermittently, but the failure is clearly not an
actual problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1825946/+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 1835738] Autopkgtest regression report (python3-stdlib-extensions/3.7.5-1~19.04)
All autopkgtests for the newly accepted python3-stdlib-extensions (3.7.5-1~19.04) for disco have finished running. The following regressions have been reported in tests triggered by the package: thonny/3.1.1-1 (s390x) python3.8/3.8.0~a3-2 (amd64, arm64, s390x, i386, armhf, ppc64el) pandas/unknown (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/disco/update_excuses.html#python3-stdlib-extensions [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1835738 Title: SRU: Update Python interpreter to 3.6.9 and 3.7.5 Status in python3-defaults package in Ubuntu: New Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python3-defaults source package in Bionic: New Status in python3-stdlib-extensions source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in python3-defaults source package in Disco: New Status in python3-stdlib-extensions source package in Disco: Fix Committed Status in python3.7 source package in Disco: New Status in python3-defaults source package in Eoan: New Status in python3-stdlib-extensions source package in Eoan: Fix Committed Status in python3.7 source package in Eoan: Fix Committed Bug description: Update Python interpreter to 3.6.9 and 3.7.5. As done with earlier subminor upstream releases (LP: #1822993). SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the 3.6.9 release. python3-stdlib-extensions also updates the modules to the 3.6.9 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. TODO: update after test rebuild http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-cosmic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1848522] Autopkgtest regression report (mesa/19.2.1-1ubuntu1~18.04.1)
All autopkgtests for the newly accepted mesa (19.2.1-1ubuntu1~18.04.1) for bionic have finished running. The following regressions have been reported in tests triggered by the package: firefox/70.0.1+build1-0ubuntu0.18.04.1 (armhf) pymol/1.8.4.0+dfsg-1build1 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#mesa [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1848522 Title: Backport packages for 18.04.4 HWE stack Status in libclc package in Ubuntu: Invalid Status in libdrm package in Ubuntu: Invalid Status in llvm-toolchain-9 package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in xorg-server-hwe-18.04 package in Ubuntu: Invalid Status in libclc source package in Bionic: Fix Committed Status in libdrm source package in Bionic: Fix Committed Status in llvm-toolchain-9 source package in Bionic: Fix Committed Status in mesa source package in Bionic: Fix Committed Status in xorg-server-hwe-18.04 source package in Bionic: New Bug description: [Impact] These are needed for 18.04.4 images. [Test case] Boot a daily image, see that it still has the necessary stack installed and working. Check upgrade from stock bionic. [Regression potential] libdrm: very minimal chance for regressions llvm-9: a new package, no regression potential on it's own libclc: more or less just adds support for new llvm mesa: a new major release, but we'll pull the final stable release of 19.2.x series, so there shouldn't be any regressions left at that point xserver: a new git snapshot (or maybe a point-release) xorg drivers: modest updates, mainly just new ati/amdgpu [Other info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libclc/+bug/1848522/+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 1846787] Autopkgtest regression report (systemd/229-4ubuntu21.23)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.23) for xenial
have finished running.
The following regressions have been reported in tests triggered by the package:
umockdev/0.8.11-2 (i386)
apt/1.2.32 (ppc64el)
unity8/8.12+16.04.20160401-0ubuntu1 (i386)
udisks2/2.1.7-1ubuntu1 (amd64)
gvfs/1.28.2-1ubuntu1~16.04.3 (s390x)
systemd/229-4ubuntu21.23 (i386)
docker.io/18.09.7-0ubuntu1~16.04.5 (i386, arm64, s390x, ppc64el, amd64)
nplan/0.32~16.04.7 (amd64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#systemd
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1846787
Title:
systemd-logind leaves leftover sessions and scope files
Status in dbus package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in dbus source package in Xenial:
In Progress
Status in systemd source package in Xenial:
Fix Committed
Bug description:
[Impact]
Scope file leakage can cause SSH delays and reduce performance in systemd
[Description]
The current systemd-logind version present in Xenial can leave abandoned SSH
sessions and scope files in cases where the host sees a lot of concurrent SSH
connections. These leftover sessions can slow down systemd performance
greatly, and can have an impact on sshd handling a great number of concurrent
connections.
To fix this issue, patches are needed in both dbus and systemd. These improve
the
performance of the communication between dbus and systemd, so that they can
handle a better volume of events (e.g. SSH logins). All of those patches are
already present from Bionic onwards, so we only need those fixes for Xenial.
== Systemd ==
Upstream patches:
- core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification
(d8fdc62037b5)
$ git describe --contains d8fdc62037b5
v230~71^2~2
$ rmadison systemd
systemd | 229-4ubuntu4 | xenial | source, ...
systemd | 229-4ubuntu21.21 | xenial-security | source, ...
systemd | 229-4ubuntu21.22 | xenial-updates | source, ... <
systemd | 237-3ubuntu10| bionic | source, ...
systemd | 237-3ubuntu10.29 | bionic-security | source, ...
systemd | 237-3ubuntu10.29 | bionic-updates | source, ...
systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...
== DBus ==
Upstream patches:
- Only read one message at a time if there are fds pending (892f084eeda0)
- bus: Fix timeout restarts (529600397bca)
- DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)
$ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
dbus-1.11.10~44
dbus-1.11.10~45
dbus-1.11.16~2
$ rmadison dbus
dbus | 1.10.6-1ubuntu3| xenial | source, ...
dbus | 1.10.6-1ubuntu3.4 | xenial-security | source, ...
dbus | 1.10.6-1ubuntu3.4 | xenial-updates | source, ... <
dbus | 1.12.2-1ubuntu1| bionic | source, ...
dbus | 1.12.2-1ubuntu1.1 | bionic-security | source, ...
dbus | 1.12.2-1ubuntu1.1 | bionic-updates | source, ...
[Test Case]
1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost
sleep 1 & done
2) Check for leaked sessions in /run/systemd/system/:
multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
