override of APT_LISTCHANGES_FRONTEND can/should be removed

[andrew bezella]

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)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "remove the APT_LISTCHANGES_FRONTEND override" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Balint Reczey (rbalint)]

Have you tried if the pager frontend hangs u-u?
https://github.com/mvo5/unattended-upgrades/pull/139#discussion_r220071922

[andrew bezella (abezella)]

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.

[Balint Reczey (rbalint)]

Fixed in 1.13. Thanks for the patch!

[Balint Reczey (rbalint)]

Sorry, not this one yet. :-(