[Bug 1633098] Re: override of APT_LISTCHANGES_FRONTEND can/should be removed

[andrew bezella]

the linked comment seems to describe a different circumstance than the
comments in setup_apt_listchanges (which does not mention the pager
frontend).  debian bug 579733 is also focused on mail behavior rather
than pager.

that said, i can confirm that u-u does NOT hang with the above patch
applied and "frontend = pager" in /etc/apt/listchanges.conf.  the apt-
listchanges output ends up in /var/log/unattended-upgrades/unattended-
upgrades-dpkg.log.

when "confirm=1" is set in listchanges.conf then u-u does stop and wait
for confirmation.  however, in my testing this happens if either the
mail or pager frontend is chosen and even when the patch is reverted (so
afaict the code in question was not meant to address this condition).
if the (self-inflicted) conflict between requiring confirmation on
upgrade while using unattended-upgrades is the concern, then it would
seem that overriding the confirmation would be more appropriate than
changing the frontend.

thanks!  please let me know if additional information is required.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to unattended-upgrades in Ubuntu.
https://bugs.launchpad.net/bugs/1633098

Title:
  override of APT_LISTCHANGES_FRONTEND can/should be removed

Status in unattended-upgrades package in Ubuntu:
  Incomplete

Bug description:
  unattended-upgrades overrides the setting of APT_LISTCHANGES_FRONTEND.
  per the comments, this was done at a time when apt-listchanges would
  "always send a mail if there is a mail address set in the config
  regardless of the frontend used."  this is no longer the case and this
  (now unnecessary) local override of APT_LISTCHANGES_FRONTEND can cause
  confusion when apt-listchanges appears to ignore its configured
  settings.

  What I expected to happen:

  i expected apt-listchanges to conform to its configuration.  setting
  the "none" frontend in /etc/apt/listchanges.conf should ensure it
  "Does nothing" as per the manpage.

  What happened instead:

  unattended-upgrades does not respect the frontend setting, essentially
  now replicating the bad behavior this snippet was originally meant to
  workaround (i.e., mail is currently sent when email_address is set but
  frontend=none).  with the attached patch the frontend specified in
  listchanges.conf is no longer unnecessarily overridden.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: unattended-upgrades 0.90
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Thu Oct 13 07:07:44 2016
  JournalErrors:
   -- Logs begin at Tue 2016-10-11 08:02:03 PDT, end at Thu 2016-10-13 07:06:49 PDT. --
   Oct 11 08:13:30 hostname systemd-tmpfiles[10524]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
   Oct 12 08:13:50 hostname systemd-tmpfiles[25099]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
  PackageArchitecture: all
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/zsh
  SourcePackage: unattended-upgrades
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1633098/+subscriptions