On 27.06.2015 00:17, Josh Triplett wrote: > On Fri, Jun 26, 2015 at 11:42:44AM +0200, Emilio Pozuelo Monfort wrote: >> 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 <george...@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. > > I wouldn't be surprised if the bug exists in previous versions of > gnome-shell as well, so allowing migration to testing seems fine.
FWIW, I indeed experienced the same problem before on an earlier major upstream version upgrade of gnome-shell. >> Josh, any chance you can try the SIGHUP approach and confirm that solves your >> problem and doesn't cause any other undesired effect? > > I've tested sending a SIGHUP to gnome-shell, and that approach causes > several significant undesired effects. > > 1) Sending SIGHUP to gnome-shell momentarily drops the screen lock. > This reveals the applications behind the screen lock, and even allows > interacting with them. (For a fraction of a second, sure, but still, > that's a security issue.) > > 2) If gnome-shell restarts twice in the same session, the second time it > puts up the "Oh no!" dialog, which only allows the user to restart their > session, losing anything they have open. So if gnome-shell has > already restarted once in the user's session for unrelated reasons, > sending SIGHUP to it will force the user to restart their session > entirely and lose any open applications. That only happens if the time between restarting gnome-shell twice is "too short". I don't know the exact threshold, but it seems to be around a few minutes. Also, it's possible (at least it used to be) to close the "Oh no!" dialogue by pressing alt-F4. Of course, that does mean the SIGHUP workaround might potentially allow a third party to circumvent the screen lock. So, I agree the SIGHUP workaround probably shouldn't be done automatically, but it might be worth at least documenting it with all its caveats, e.g. in NEWS.Debian.gz. > I think it's going to be necessary to teach gnome-shell to handle screen > unlocking after an upgrade. I've forwarded this bug upstream to > https://bugzilla.gnome.org/show_bug.cgi?id=751544 . I'm afraid live upgrades might not be a use-case GNOME upstream cares about. :( -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
