polkit permissions checks should be non-interactive for background operations
Starting about 23 days ago (2019-01-03 - that's the earliest occurrence I can find in the backlog), there's an occasional failure that occurs in the Fedora openQA graphical update test, only when run on pending updates for Fedora 29.
What this test does is:
- Boot a base disk image which is a Fedora 29 Workstation install created by virt-install
- Log in as a user account that was created by virt-install and run through user initial-setup
- Switch to a console, download the packages from the update that is being tested, create a repo containing them, enable that repo on the system
- Run 'dnf -y update' to install any packages from the update that are installed on the system
- Reboot
- Log in again
- Switch to a console
- Set up a new repo config for a special test repo that contains a dummy
python3-kickstart-1-1
package, then install that package; this is to ensure an update will be available for GNOME Software to install - Switch back to the desktop
- Run GNOME Software and install updates
The intent of the test is to check that the update does not break the process of doing a system update with GNOME Software. When this bug happens, it happens after step 9: when the test switches back to the GNOME desktop, instead of seeing a normal desktop and being able to launch Software (which is what it expects), the test sees this screen:
Just to be clear, this happens before the test actually tries to launch Software, so it is presumably being triggered by a background repo refresh that Software / PackageKit does (probably the 'on first login after boot' refresh).
This does not happen on Fedora 28 update tests, so the bug is apparently not in Fedora 28. It also does not happen on Fedora Rawhide nightly compose tests, suggesting either that the bug is not in Rawhide, or that the differences in how the test runs on composes versus pending updates is significant: basically, when run on composes, the base image is not produced by virt-install but by an earlier test that installs the Workstation live image from the compose using anaconda interactively, and steps 3 through 6 do not happen (because we are not testing an update in this case).
The versions of gnome-software and PackageKit in F28, F29 and Rawhide at present are:
- F28 (not affected): gnome-software-3.28.2-4.fc28, PackageKit-1.1.10-1.fc28
- F29 (affected): gnome-software-3.30.6-1.fc29, PackageKit-1.1.12-2.fc29
- Rawhide (not affected): gnome-software-3.31.2-1.fc30, PackageKit-1.1.12-2.fc30
Here is a tarball of /var/log from the earliest occurrence of this bug: desktop_update_graphical-var_log.tar.gz
Note that gnome-software-3.30.6-1.fc29 and PackageKit-1.1.12-2.fc29 were part of an update that was pushed stable on 2018-12-22. That's a couple of weeks before the bug started showing up, but note that the 'base disk image' mentioned above is regenerated every two weeks. So it seems a reasonable theory that this bug started showing up when that update got pulled into the openQA base disk image for Fedora 29. The versions that were in Fedora 29 before that update were gnome-software-3.30.5-1.fc29 and PackageKit-1.1.12-1.fc29.