[Bug 1821412] Autopkgtest regression report (update-notifier/3.192.40.4)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted update-notifier (3.192.40.4) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

update-notifier/3.192.40.4 (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/hirsute/update_excuses.html#update-notifier

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  "System program problem" report button does nothing

Status in update-notifier package in Ubuntu:
  Fix Released
Status in update-notifier source package in Bionic:
  Won't Fix
Status in update-notifier source package in Focal:
  Fix Committed
Status in update-notifier source package in Hirsute:
  Fix Committed
Status in update-notifier source package in Impish:
  Fix Committed

Bug description:
  [Impact]
    * Users, already annoyed that software has crashed and they have an
      unwanted dialog instead, are unable to click the report button to
      let us know about the crash.
    * Two identical-looking dialogs exist - one on the system-crash
      path, and one spawned by the background update-notifier process.
      The system crash one is the failing one, the update-notifier one
      is fine.  The system crash one shows first, and users may not
      bother to approve the second one given that the first didn't do
      anything
    * We receive fewer crash reports

  [Test Plan]
    * sudo xeyes &
    * sudo kill -11 $PID from above
    * receive crash notification
    * click "Report problem..."
    * We should see the report procedure start

  [Where problems could occur]
    * By the nature of the supplied fix, if the report process hangs
      around, the normal systemd cleanup procedures would fail to clean
      it up.  This same risk is present for report processes initiated
      on the non-system-crash report code path.
    * Wayland is still affected even with this fix, for different reasons
      (LP: #1947929)

  [Other Info]
  Q: Systemd says KillMode=process is not recommended
  https://www.freedesktop.org/software/systemd/man/systemd.kill.html

  In this case, killing the other processes in the control-group is part
  of the problem.

  The system crash dialog is a relatively simple bit of code that shows
  a dialog, then runs a report process.  This dialog process is spawned
  as part of a chain of processes downstream from
  update-notifier-crash.service.

  This dialog runs the report process using g_spawn_async().  After
  spawning the report process, there isn't any particular reason to keep
  the dialog process around, so it exits.  This exit is triggering the
  KillMode behavior, and because the report process is in the control
  group, the report process is killed.

  Another possibility for addressing the process management is to run
  the report process synchronously - keep the dialog process around
  until the report is done and just make the dialog not visible.  This
  is not a workable answer in this case because with the current gtk
  code usage, the dialog sticks around - even after the call to
  gtk_widget_destroy()!  This appears to be due to usage of
  gtk_dialog_run().  Long term I recommend we modernize this code.
  My initial fix for this LP was in that direction.
  https://git.launchpad.net/~dbungert/update-notifier/commit/?id=06058d5705ed7cd636206c1ee72c376ec903fe74

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1821412/+subscriptions