[03:21] Ahem. I appear to have just managed to crash the GNOME Shell lock screen back to my session. [03:21] I thought that wasn't meant to be possible. [03:37] 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] Just noticed I've got the dock displaying over the top of the lock screen [03:42] which is useful to start or stop applications without restarting [03:42] that might be 1769383 or 1803595 [03:42] maybe both [03:45] Yes... jamesh: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1769383 [03:45] Ubuntu bug 1769383 in gnome-shell-extension-ubuntu-dock (Ubuntu Disco) "Ubuntu dock/launcher is shown on the lock screen" [High,In progress] [03:48] I'm pretty sure I haven't installed dash-to-dock [03:48] just have ubuntu-dock installed [03:48] jamesh, that's an Ubuntu dock bug [03:49] duflu: the reproduction instructions seem to be about having both installed [03:49] jamesh, I am correcting that user now :) [03:53] jamesh, herding cats... where those "cats" are people who install gnome-shell extensions and break their machines in countless other ways [03:58] Oh, that's right. [03:59] The lock screen is provided by gnome-shell, so if it dies you're back in the session. [03:59] 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] RAOF: I agree with that statement but do not know the details [04:07] 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] duflu: I found a GJS stack trace related to ubuntu-dock in the journal. That could be related. [04:07] attached to the bug now [04:09] you'd think every screenlocker author would know that a five year old is mandatory testing equipment.. === JanC_ is now known as JanC [04:15] 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] jamesh, can you find an error message that was above the stack trace? [04:37] 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] andyrock: gnome-shell[5626]: Object Meta.WindowActor (0x560d5092bb [04:37] 00), has been already deallocated — impossible to access it. This might be cause [04:37] d by the object having been destroyed from C code using something such as destro [04:37] y(), dispose(), or remove() vfuncs. [04:38] stupid autocomplete. that was just "and:" [04:39] It's not obviously connected to the stack trace [05:00] jamesh, that second one is what I would expect to see associated with stack traces [05:00] Although its unclear if any of this is really related to the bug [05:00] yep. I see multiple occurences of it. [05:01] does gnome-shell attempt to disable extensions when locking the screen? [05:06] No idea [05:35] duflu: it is definitely disabling and enabling extensions during lock/unlock. So failing to disable the extension leaves it active on the lock screen === Class7_ is now known as Class7 [06:06] jamesh, do you mean disabling or just hiding? [06:06] I mean they would still be resident most likely [06:06] duflu: I think they stay resident, but their disable() function is called on lock, and enable() on unlock [06:07] OK. So there are two definitions of disable for extensions :S [06:08] it's probably the same code path that gets run when you toggle them in gnome-shell-extension-prefs or the website [06:08] That makes me more concerned in general. It means any buggy extension that is installed and disabled could still break the shell [06:08] yep. [06:10] Despite being written in an interpreted language, they've got a similar ability to corrupt the application state as C code would [06:10] 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] 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] 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] I guess ubuntu-dock looks like a similar screen element [06:12] 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] Damn, /Summer is Coming/ [06:58] good morning [07:01] Hi didrocks [07:02] hey duflu [07:41] good morning === ecloud_wfh is now known as ecloud [08:37] good morning desktoppers [08:49] Morning ricotz and oSoMoN [08:52] hey duflu, ricotz [08:57] oSoMoN, duflu, hi [09:02] fwoop fwoop [09:42] 📢 Hi Laney [09:44] hi! [09:45] Hi there Nafallo [09:45] and with that I shall prepare to weekend [09:45] :-) [09:45] had I known I was your indicator I would have said hi sooner ;-) [10:34] no seb? [10:36] not today [10:38] ok [11:28] 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] Laney, hi, could you sync vala 0.42.3-1 from debian? [11:45] ricotz: it will autosync [11:46] oh, I see, I expected this would have happened already, that is why I asked [11:48] I think it's off atm due to ongoing transitions, but should be back soon [12:39] tseliot: works for me, thanks! btw, is 410 planned for 19.04? [12:41] ginggs: yes, I have it in a ppa for testing [12:41] ginggs: https://launchpad.net/~albertomilone/+archive/ubuntu/nvidia-glvnd-temp [12:45] tseliot: thanks, i'll give it a spin with cuda 9.2 and 10 soon [12:54] ginggs: thanks [14:24] Good morning === pstolowski is now known as pstolowski|afk === meetingology` is now known as meetingology [19:34] have a good week-end desktoppers! [23:13] kenvandine: I'm getting that popup in firefox snap again telling me it can't update :( [23:23] popey: yeah, oSoMoN filed a bug about it [23:24] popey: I'll probably have him work on it after he finishes some other stuff [23:24] If nobody else fixes it first [23:24] surely there's some build-time flag we can set? [23:24] because the deb surely doesn't do this [23:24] Nope [23:24] The deb pops this up? [23:25] Not sure [23:25] This is a new thing in Firefox [23:26] There might be some logic in the code for those packages [23:26] That isn't honored in the snap [23:26] Oh right, because Firefox isn't built just for the snao [23:27] So even if there is a build flag, it wouldn't help for the snap [23:27] The snap is built from the same binary they release [23:27] ah [23:29] popey: so we need some runtime logic to disable this [23:29] https://support.mozilla.org/en-US/questions/1197474 [23:29] Which Mozilla has done for some other things in the snap [23:29] https://support.mozilla.org/en-US/questions/1233924 [23:31] seems other (enterprise users) have also made noise about this