group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1821101@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package unattended-upgrades -
1.1ubuntu1.18.04.7~16.04.3

---------------
unattended-upgrades (1.1ubuntu1.18.04.7~16.04.3) xenial; urgency=medium

  * Detect changes to moved conffiles (LP: #1823872)
    - Add tests for checking conffile moves.
      Build depend on and use equivs to generate new test packages
    - Split() conffile data to set of names only once
    - Don't parse dpkg conffile db when there are no conffiles in the package
  * Detect unchanged moved conffiles.
    When a package moves a conffile properly without any change no conffile
    prompt needs to be shown thus the package can be upgraded unattended.
    (LP: #1823872)
  * Skip sending email when no package had to be installed, upgraded or removed
    (LP: #1821103) (Closes: #924554)
  * Make sure autoremovals don't start with a dirty cache and remove other
    packages (LP: #1824341)
  * Continue applying minimal sets when one set can't be marked for upgrade.
    Thanks to Anderson Luiz Alves for the patch, it needed minor modifications
    (LP: #1824341)
  * Stop raising NoAllowedOriginError when marking packages to upgrade/install
    fails (LP: #1824876)
  * Adjust only transitive dependencies in the fallback when a package from an
    allowed origin can't be marked to install/upgrade.
    This is a much lighter approach than marking every upgradable package
    because the full fallback was triggered on packages held back as well,
    using an excessive amount of CPU time.
    Also it crashed with packages not having any version in allowed origins.
    (LP: #1824804, #1824949)
  * Skip trying to upgrade held packages in call_adjusted() (LP: #1824804)
  * Follow all kinds of transitive dependencies when adjusting dependencies
  * Don't crash collecting transitive dependencies when package has no candidate
    (LP: #1825886)
  * Use mark_install_adjusted() in rewind_cache()
    The original cache had packages marked with adjustments thus rewinding
    should also do adjustments to reach the same state.
    Also not using mark_install_adjusted() crashes when apt raises error on
    held packages. (LP: #1826157)
    - test_rewind: Update test to check if adjustend rewinding took place
  * do_auto_remove() is successful unless a commit() operation fails
    (LP: #1795696)
  * Compare apt.package.Version objects and not the versions' string
    representation. (LP: #1820888)
    This prevented adjusting candidates when the strings sorted differently.
    Also extend tests to catch issue.
  * Fall back to adjusting more packages' candidates
    when a package from an allowed origin can't be marked to install/upgrade.
    (LP: #1821101)

 -- Balint Reczey <rbalint@xxxxxxxxxx>  Mon, 29 Apr 2019 12:23:14 +0200

** Changed in: unattended-upgrades (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Xenial:
  Fix Released
Status in unattended-upgrades source package in Bionic:
  Fix Released
Status in unattended-upgrades source package in Cosmic:
  Fix Released

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