[03:21] <RAOF> Ahem. I appear to have just managed to crash the GNOME Shell lock screen back to my session.
[03:21] <RAOF> I thought that wasn't meant to be possible.
[03:37] <duflu> RAOF: I would not have imagined so. Can you try looking for evidence? https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment
[03:41] <jamesh> Just noticed I've got the dock displaying over the top of the lock screen
[03:42] <jamesh> which is useful to start or stop applications without restarting
[03:42] <sarnold> that might be 1769383 or 1803595
[03:42] <sarnold> maybe both
[03:45] <duflu> Yes... jamesh: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1769383
[03:48] <jamesh> I'm pretty sure I haven't installed dash-to-dock
[03:48] <jamesh> just have ubuntu-dock installed
[03:48] <duflu> jamesh, that's an Ubuntu dock bug
[03:49] <jamesh> duflu: the reproduction instructions seem to be about having both installed
[03:49] <duflu> jamesh, I am correcting that user now :)
[03:53] <duflu> jamesh, herding cats... where those "cats" are people who install gnome-shell extensions and break their machines in countless other ways
[03:58] <RAOF> Oh, that's right.
[03:59] <RAOF> The lock screen is provided by gnome-shell, so if it dies you're back in the session.
[03:59] <RAOF> duflu: I don't have a crash file (it might have auto-submitted), but if there's code that tries to ensure that GS comes back as a lock screen if it crashes while being at the lock screen, that code is buggy :)
[04:00] <duflu> RAOF: I agree with that statement but do not know the details
[04:07] <RAOF> Hm. I don't think “baby mashing keys at the lock screen crashes GS which then restarts into the session” is a particularly actionable bug, sadly. I don't seem to have an apport dump for that.
[04:07] <jamesh> duflu: I found a GJS stack trace related to ubuntu-dock in the journal.  That could be related.
[04:07] <jamesh> attached to the bug now
[04:09] <sarnold> you'd think every screenlocker author would know that a five year old is mandatory testing equipment..
[04:15] <RAOF> The good thing here is that switching to Wayland fixes it (by making every gnome-shell crash kill every process in the session ☺)
[04:21] <duflu> jamesh, can you find an error message that was above the stack trace?
[04:37] <jamesh> duflu: there are a number of ones like: gnome-shell[5626]: ../../../../gobject/gsignal.c:2641: instance '0x560d42322850' has no handler with id '6357714'
[04:37] <jamesh> andyrock: gnome-shell[5626]: Object Meta.WindowActor (0x560d5092bb
[04:37] <jamesh> 00), has been already deallocated — impossible to access it. This might be cause
[04:37] <jamesh> d by the object having been destroyed from C code using something such as destro
[04:37] <jamesh> y(), dispose(), or remove() vfuncs.
[04:38] <jamesh> stupid autocomplete.  that was just "and:"
[04:39] <jamesh> It's not obviously connected to the stack trace
[05:00] <duflu> jamesh, that second one is what I would expect to see associated with stack traces
[05:00] <duflu> Although its unclear if any of this is really related to the bug
[05:00] <jamesh> yep.  I see multiple occurences of it.
[05:01] <jamesh> does gnome-shell attempt to disable extensions when locking the screen?
[05:06] <duflu> No idea
[05:35] <jamesh> duflu: it is definitely disabling and enabling extensions during lock/unlock.  So failing to disable the extension leaves it active on the lock screen
[06:06] <duflu> jamesh, do you mean disabling or just hiding?
[06:06] <duflu> I mean they would still be resident most likely
[06:06] <jamesh> duflu: I think they stay resident, but their disable() function is called on lock, and enable() on unlock
[06:07] <duflu> OK. So there are two definitions of disable for extensions :S
[06:08] <jamesh> it's probably the same code path that gets run when you toggle them in gnome-shell-extension-prefs or the website
[06:08] <duflu> That makes me more concerned in general. It means any buggy extension that is installed and disabled could still break the shell
[06:08] <jamesh> yep.
[06:10] <jamesh> Despite being written in an interpreted language, they've got a similar ability to corrupt the application state as C code would
[06:10] <duflu> jamesh, I don't think "disable" is the right way to expect shell elements to be hidden under the lock screen though. That should be a simple paint ordering issue
[06:11] <duflu> But that's just my expectation and maybe not how it works
[06:11]  * duflu glares at the Unity launcher he spent so many hours fixing the paint ordering for
[06:12] <jamesh> well, elements like the top panel are the same on the lock screen.  The different session mode just turns some elements like the app and settings menus on and off
[06:12] <jamesh> I guess ubuntu-dock looks like a similar screen element
[06:12] <duflu> I mean that gnome-shell comes with a dock of its own. We should be able to hide the ubuntu-dock in the same way as the default one gets hidden. That's not an extension
[06:17] <duflu> Damn, /Summer is Coming/
[06:58] <didrocks> good morning
[07:01] <duflu> Hi didrocks
[07:02] <didrocks> hey duflu
[07:41] <ricotz> good morning
[08:37] <oSoMoN> good morning desktoppers
[08:49] <duflu> Morning ricotz and oSoMoN
[08:52] <oSoMoN> hey duflu, ricotz
[08:57] <ricotz> oSoMoN, duflu, hi
[09:02] <Laney> fwoop fwoop
[09:42] <duflu> 📢 Hi Laney
[09:44] <Nafallo> hi!
[09:45] <duflu> Hi there Nafallo
[09:45] <duflu> and with that I shall prepare to weekend
[09:45] <Nafallo> :-)
[09:45] <Nafallo> had I known I was your indicator I would have said hi sooner ;-)
[10:34] <tjaalton> no seb?
[10:36] <Laney> not today
[10:38] <tjaalton> ok
[11:28] <tseliot> bcurtiswx: I have just uploaded nvidia-graphics-drivers-390_390.87-0ubuntu3 . That will fix the problem with linux 4.18.0-10-generic
[11:45] <ricotz> Laney, hi, could you sync vala 0.42.3-1 from debian?
[11:45] <Laney> ricotz: it will autosync
[11:46] <ricotz> oh, I see, I expected this would have happened already, that is why I asked
[11:48] <Laney> I think it's off atm due to ongoing transitions, but should be back soon
[12:39] <ginggs> tseliot: works for me, thanks!  btw, is 410 planned for 19.04?
[12:41] <tseliot> ginggs: yes, I have it in a ppa for testing
[12:41] <tseliot> ginggs: https://launchpad.net/~albertomilone/+archive/ubuntu/nvidia-glvnd-temp
[12:45] <ginggs> tseliot: thanks, i'll give it a spin with cuda 9.2 and 10 soon
[12:54] <tseliot> ginggs: thanks
[14:24] <jibel> Good morning
[19:34] <oSoMoN> have a good week-end desktoppers!
[23:13] <popey> kenvandine: I'm getting that popup in firefox snap again telling me it can't update :(
[23:23] <kenvandine> popey: yeah, oSoMoN filed a bug about it
[23:24] <kenvandine> popey: I'll probably have him work on it after he finishes some other stuff
[23:24] <kenvandine> If nobody else fixes it first
[23:24] <popey> surely there's some build-time flag we can set?
[23:24] <popey> because the deb surely doesn't do this
[23:24] <kenvandine> Nope
[23:24] <popey> The deb pops this up?
[23:25] <kenvandine> Not sure
[23:25] <kenvandine> This is a new thing in Firefox
[23:26] <kenvandine> There might be some logic in the code for those packages
[23:26] <kenvandine> That isn't honored in the snap
[23:26] <kenvandine> Oh right, because Firefox isn't built just for the snao
[23:27] <kenvandine> So even if there is a build flag, it wouldn't help for the snap
[23:27] <kenvandine> The snap is built from the same binary they release
[23:27] <popey> ah
[23:29] <kenvandine> popey: so we need some runtime logic to disable this
[23:29] <popey> https://support.mozilla.org/en-US/questions/1197474
[23:29] <kenvandine> Which Mozilla has done for some other things in the snap
[23:29] <popey> https://support.mozilla.org/en-US/questions/1233924
[23:31] <popey> seems other (enterprise users) have also made noise about this