All autopkgtests for the newly accepted fwupd (1.7.9-1~20.04.1) for focal have finished running. The following regressions have been reported in tests triggered by the package:
fwupd/1.7.9-1~20.04.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/focal/update_excuses.html#fwupd [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/1969976 Title: DynamicUser=1 doesn't get along with services that need dbus-daemon Status in Fwupd: Fix Released Status in OEM Priority Project: Confirmed Status in systemd: New Status in fwupd package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Won't Fix Status in fwupd source package in Focal: Fix Committed Status in systemd source package in Focal: Won't Fix Status in fwupd source package in Impish: Won't Fix Status in systemd source package in Impish: Won't Fix Status in fwupd source package in Jammy: Fix Committed Status in systemd source package in Jammy: Won't Fix Bug description: Updating to systemd 245.4-4ubuntu3.16 has caused a regression in Ubuntu 20.04, that fwupd-refresh.service always fails to run. This has been root caused down to the changes in https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538 Unfortunately this is an upstream issue introduced by stable systemd. https://github.com/systemd/systemd/issues/22737 The problem also occurs in Ubuntu 22.04 with a newer systemd release. As discussed in https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/comments/61 it's a tradeoff of issues. So within Ubuntu something probably needs to be done about fwupd-refresh.service. One proposal is to remove DynamicUser=yes from the systemd unit, but this will mean fwupdgmr refresh runs as root. It's relatively sandboxed by other security mechanisms, but still not ideal. Could we repurpose any other service account? Or alternatively we can make a new fwupd service account that this systemd unit uses. To manage notifications about this bug go to: https://bugs.launchpad.net/fwupd/+bug/1969976/+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
