Hello Balint, or anyone else affected, Accepted unattended-upgrades into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source /unattended-upgrades/1.1ubuntu1.18.04.10 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1821101 Title: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Bionic: Fix Committed Status in unattended-upgrades source package in Cosmic: Fix Committed Bug description: [Impact] * Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:falling back to marking test2-package, then adjusting changes DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:falling back to marking test3-package, then adjusting changes WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) DEBUG:root:falling back to adjusting all packages DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 WARNING:root:package z-package upgradable but fails to be marked for upgrade () . ---------------------------------------------------------------------- Ran 1 test in 0.039s OK [Regression Potential] * When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash. * In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression. [Other Info] * If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again: See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821101/+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
