The rfkill code will cancel any running task when a new task comes in.
This makes sense in most cases, but the code would cancel the
cancellable from the outside scope which may be reused. This effectively
resulted in all changes to be cancelled immediately when this
compression happened once.

Fix the issue by creating a new cancellable and propagating the
cancelled state rather then setting it on the passed in cancellable.

Seems like this broke in the move to meson. Rather than trying to set it
inside the binary, set the environment variable in meson.

(cherry picked from commit ea8e9144)

Without this we need to install the GSchema files for testing purposes.

(cherry picked from commit c5665d3e)

A smooth transition between two color temperatures might still be active
when the next color temperature is set. Cancel any pending transitions
in this case.

This possibly fixes issues where the colour temperature is stuck in
night mode even though it is daytime.

Benjamin Berg authored Mar 15, 2018 and Carlos Garnacho committed Apr 12, 2018

Moving this is important, as gnome-session (or to be exact the
acceleration check) requires the environment variable to be set already.

Mantas Mikulėnas authored Feb 05, 2018 and Bastien Nocera committed Mar 31, 2018

On slower machines (esp. with tracker and/or dropbox starting on login)
this may take more than the usual timeout of ~25 seconds.

We cannot use the existing retry loop here – in this bug, the first call
actually *succeeds* from gnome-shell's side, even if gsd-mediakeys gives
up on waiting for the reply.

So if we called GrabAccelerators again, we would receive no accel IDs
(because all keys are duplicates), and gnome-shell would keep sending
AcceleratorActivated signals with accel IDs that the 1st call has
established – resulting in exactly the same "Could not find accelerator
for accel id" as we're trying to fix.

https://bugzilla.gnome.org/show_bug.cgi?id=792353

To make debugging issues with the automatic timezone feature easier.

https://bugzilla.gnome.org/show_bug.cgi?id=794288

The test suite will print those 'comments', so use '#' to comment them
instead.

The error we'd have gotten from the keyboard brightness test when
gsd-power crash obviously wouldn't match that returned by gsd-power.
Check the error in details to make sure that the error matches our
expectations.

Like the interface name, to make sure that the error matches our call.

Otherwise gnome-session might try to use an unmocked upowerd on the
system, causing crashes with our mock logind.

The xorg log fd position will be after the written error, so re-open the
log to read, and check for the expected error.