Bug#789118: No issues with clean upgrade

[Emilio Pozuelo Monfort]

Control: found -1 3.14.4-1

On 22/06/15 02:36, Michel Dänzer wrote:
> On 22.06.2015 03:39, Josh Triplett wrote:
>> On Sun, Jun 21, 2015 at 07:52:10PM +0200, Michael Biebl wrote:
>>> Am 20.06.2015 um 08:54 schrieb Michel Dänzer:
>>>> On Thu, 18 Jun 2015 21:19:20 +0400 George Hertz <georgedot at gmail.com> wrote:
>>>>> I've just upgraded to 3.16 on unstable, but restarted the system right 
>>>>> after the update finished.
>>>>>
>>>>> No problems unlocking.
>>>>
>>>> Yeah, the problem only occurs with a gnome-shell which is already
>>>> running during the upgrade.
>>>>
>>>> However, the problem also occurs when only locking the session after the
>>>> upgrade has completed.
>>>>
>>>> One possible workaround after the upgrade is
>>>>
>>>> 	killall -HUP gnome-shell gnome-settings-daemon
>>
>> I didn't know you could HUP gnome-shell to unlock the session; that's
>> useful to know.
>>
>>>> Sending SIGHUP to gnome-shell only is enough to be able to unlock the
>>>> session, but gnome-settings-daemon also needs to be restarted, or some
>>>> things such as keyboard shortcuts don't work properly in the new
>>>> gnome-shell.
>>>
>>> Unfortuantely we don't have a proper mechanism to restart programs in
>>> the desktop session. Using killall in postinst is something I'd be wary
>>> about.
>>
>> It's also not OK to unexpectedly unlock someone's session due to a
>> concurrent upgrade; "can't unlock my session" is bad, but "unlocked my
>> screen during upgrade" is a critical security bug.
> 
> SIGHUP doesn't unlock the session, it just makes gnome-shell restart
> itself, after which the upgraded version of gnome-shell runs and
> unlocking the session works normally.

This bug is preventing testing migration, which is causing a lot of other bugs
because of version mismatches between gtk+, gnome-settings-daemon and
mutter/gnome-shell (see e.g. #789618, #789891, #789866, #789725, #789575,
#789484...). I've talked about it to some team members and we agreed that this
is RC, but that it'd be better to let gnome-shell migrate for the time being. So
I'm doing some trick to let it migrate, but we'll fix this.

Josh, any chance you can try the SIGHUP approach and confirm that solves your
problem and doesn't cause any other undesired effect?

Thanks,
Emilio