=== pstolowski|afk is now known as pstolowski
[07:17] <duflu> Hi seb128. Welcome home :)
[07:17] <duflu> In more ways than one
[07:18] <seb128> good morning desktopers
[07:18] <seb128> hey duflu, thanks, how are you today?
[07:18] <duflu> seb128, very good. You?
[07:19] <seb128> I'm good thanks, a bit tired or not fully awake yet though :)
[07:20] <seb128> or maybe a bit of allergy, difficult to say :/
[07:50] <duflu> seb128, bluetooth meeting?
[07:50]  * duflu votes not
[07:50]  * seb128 same
[07:51] <duflu> jibel ^
[07:51] <seb128> I don't have anything to contribute and I'm still catching up on things post GUADEC
[07:59] <willcooke> morning all
[08:00] <willcooke> duflu I think we should just cancel the bluez meeting at this point
[08:00] <duflu> willcooke, agreed. koza hasn't reappeared for some time
[08:00] <duflu> Morning willcooke
[08:02] <seb128> hey willcooke, how are you?
[08:03] <willcooke> morning seb128.  Doing well, ache today having done some excercise for the first time in about 2 months yesterday.  It's a nice pain though ;)
[08:03] <seb128> nice, what sort of exercice did you do?
[08:04]  * tsimonq2 scratches his head and wonders how bug 1532508 was properly fixed...
[08:04] <ubot5> bug 1532508 in GNOME Shell "Screen contents revealed briefly on resume, before even unlocking" [Medium,In progress] https://launchpad.net/bugs/1532508
[08:05] <tsimonq2> (I'm not complaining, but I want it for LXQt. :P)
[08:05] <willcooke> seb128, golf!
[08:05] <seb128> ah, of course :)
[08:06] <willcooke> The only kind of excercise I do
[08:06] <seb128> tsimonq2, I don't think bugfix from one codebase apply as a magical recipe to another
[08:06] <seb128> but I think the main trick is to paint the lock screen before issuing the suspend
[08:06] <willcooke> tsimonq2, I /think/ it was and ordering issue.  Pulling down the screen lock shutter and inhibiting suspend while it does it, then going in to suspend
[08:06] <seb128> and ensure the frame made it to the screen also
[08:07] <willcooke> yeah, I think the trick was to make sure the lock screen had finished painting
[08:07] <seb128> if you don't inhibit the suspend that might kicks in before the lock is rendered
[08:07] <tsimonq2> But just locking before suspend doesn't fix it, you have to make sure it paints?
[08:07] <tsimonq2> (If I'n understanding you right.)
[08:08] <tsimonq2> *I'm
[08:08] <seb128> yes
[08:08] <tsimonq2> OK, I'll do some wabbit hunting.
[08:08] <tsimonq2> Thanks.
[08:08] <seb128> yw
[08:18] <oSoMoN> good morning desktoppers
[08:19] <tsimonq2> Hey oSoMoN, how's it going?
[08:20] <seb128> hey oSoMoN, how are you?
[08:20] <oSoMoN> hey tsimonq2, seb128
[08:20] <oSoMoN> I'm good, you?
[08:21] <seb128> I'm good, a bit tired|sick|allergic though
[08:22] <seb128> I woke up with a bit of a blocked nose and my eyes itching a bit, unsure if that's a post travel start of cold or just me being allergic to some plants around here
[08:22] <doko> seb128: libsoxr promoted. please be aware there is a new upstream not packaged in debian
[08:23] <seb128> doko, thanks for the notice
[08:23] <seb128> duflu, ^
[08:23] <duflu> doko, yeah I saw the bug mail already. Thank you muchly
[08:23] <oSoMoN> seb128, hopefully that's *just* the regular ubuflu
[08:24] <duflu> Morning oSoMoN
[08:24] <oSoMoN> hey duflu
[08:24] <seb128> oSoMoN, enough ubuflu for this year!
[08:25] <oSoMoN> seb128, get some better ubuantibodies!
[08:25] <seb128> :)
[08:35] <Laney> moin!
[08:39] <oSoMoN> hey Laney, didrocks
[08:39] <seb128> hey Laney, how is GUADEC going? good  BOFs yesterday?
[08:40] <didrocks> hey oSoMoN, seb128
[08:40] <Laney> hey oSoMoN seb128
[08:41] <Laney> yes, not so bad, we were mainly talking about theming and related stuff
[08:41] <Laney> the idea was to reduce the surface of theming, not sure if that's going to work but we'll see
[08:41] <willcooke> andyrock, around?  JamieBennett has livepatch configured and g-o-a is using 98GB of virt. mem after a few mins of running.  Any ideas where to start looking?
[08:41] <willcooke> cc seb128 ^
[08:42] <Laney> that's webkit GigaCage and isn't real used memory
[08:44] <willcooke> Laney, ah.  Any ideas what would cause it to report that?
[08:45] <willcooke> and would a valid thing to do be to kill g-o-a and see if the machine starts responding normally agian?
[08:46] <Laney> it's probably best to respond with a link https://labs.mwrinfosecurity.com/blog/some-brief-notes-on-webkit-heap-hardening/
[08:47] <seb128> willcooke, that's not real usage, you can try but I doubt that's what is making the machine unresponsive
[08:49] <Laney> indeed
[08:54] <willcooke> hi jamesh
[08:54] <JamieBennett> @willcooke this is a paste from the wake up this morning including a reboot from a hard reset, be warned, it's big but contains pretty much the same thing repeated: https://pastebin.canonical.com/p/Wvy8dnMbw6/
[08:54] <willcooke> oops sorry jamesh, I meant hi JamieBennett
[08:55] <jamesh> hello anyway :)
[08:56] <willcooke> JamieBennett, thanks.  g-o-a using a lot of vmem is likely a red herring, and these crashes are probably not caused by g-o-a
[08:57] <willcooke> they could still be memory related though
[08:59] <willcooke> duflu, have you seen crashes like in the logs ^ around 09:31:32 - lots of stack traces for GNOME Shell by the looks of it
[08:59] <didrocks>  /msg seb128 salut ! bon ben, le sort s'acharne quoi… :p
[08:59] <didrocks>  /#hatefootball
[08:59] <seb128> lol
[08:59] <JamieBennett> @willcooke It seems to be reproducible just by leaving the laptop idling overnight
[09:00] <seb128> France France France
[09:00]  * duflu is still waiting for the page to load
[09:00] <didrocks> We are in for 20 more years of hearing about it :(
[09:00] <JamieBennett> @willcooke when it comes to using it in the morning, the screen comes on and everything grinds to a halt in a few seconds
[09:01] <willcooke> I think it could still be realted to the thunderbolt dock.  My machine has been on for weeks and doesn't show the same problems
[09:01] <duflu> willcooke, JamieBennett, that would be bug 1772677
[09:01] <ubot5> bug 1772677 in gnome-shell (Ubuntu) "gnome-shell filling up syslog with thousands of entries (stack traces ending in osdWindow.js:206/207)" [High,Confirmed] https://launchpad.net/bugs/1772677
[09:01] <willcooke> JamieBennett, is there anything in /var/crash ?
[09:02] <didrocks> I don't think the virt mem is related to this anyway, it only depends on how much the daemon requests memory. I have 112G for deja-dup, 97 for g-oa-, 84.1 for chrome-nacl
[09:03] <JamieBennett> @willcooke no
[09:06] <duflu> willcooke, I made a little progress in comment #10 of that bug but did not chase it without a way to reproduce the bug
[09:08] <willcooke> ah
[09:09] <willcooke> so realted to monitors
[09:09] <willcooke> realted
[09:09] <willcooke> related
[09:09] <willcooke> JamieBennett, any docking/undocking going on?
[09:10] <JamieBennett> laptop is plugged in to a 4k monitor via a usb c dock
[09:10] <duflu> willcooke, no I don't think it's related to multi-monitor, only to machines with more than zero monitors
[09:10] <duflu> But maybe....?
[09:12] <willcooke> hidpi?  Is 4k counted as high dpi?  I guess it depends on the physical screen size
[09:12] <willcooke> JamieBennett, do you have shell scaling on your 4k screen?
[09:14] <JamieBennett> willcooke: monitor is 27", 100% scale
[09:14] <willcooke> kk
[09:14] <JamieBennett> running at 3840x2160
[09:15] <duflu> Actually even comment #10 might be wrong. We'll need to figure out how to reproduce it and then a developer can start poking that code.
[09:16] <JamieBennett> duflu: well, leaving my laptop plugged in over night seems to reproduce it pretty well
[09:16] <duflu> Worth noting gnome-shell upstream has similar errors in a different location. Trevinho fixed that for us but upstream hasn't accepted his fix still
[09:17] <JamieBennett> Another oddity than may be unrelated is that the screen seems to go to sleep and wake up regularly (probably notification related) as I often see the black screen turn on for no apparent reason despite not touching it
[09:19] <duflu> JamieBennett, are you able to leave the machine in a "quiet" state where any apps causing notifications are closed over night? I've been wondering if that was the trigger
[09:20] <JamieBennett> I can later today and report back
[09:20] <JamieBennett> actually, I could just switch machines and do it now
[09:30] <JamieBennett> ok, very quick test, the laptop wakes up every 10 seconds or so, powers the laptop screen then the monitor and sleeps the displays again after about 3 seconds with *no* applications or tray icons running
[09:30] <JamieBennett> I wonder if the hub is waking it (it also has usb and ethernet plugged in)
[09:34] <JamieBennett> Right, the hub keeps waking the screen but it is not USB or ethernet, it looks like the monitor itself. Laptop screen goes blank, monitor goes blank, monitor scans other inputs in a round robin, goes back to hdmi and 'wakes' the laptop back up.
[09:34] <JamieBennett> Anyone else seen that?
[09:35] <willcooke> huh
[09:35] <willcooke> So the monitor could be requesting the machine wakes up?
[09:35] <duflu> JamieBennett, you might be able to set the monitor to not auto-scan
[09:35] <JamieBennett> Well, when it settles back on hdmi it 'wakes' the laptop for some reason
[09:36] <JamieBennett> duflu: I'll turn off autoscan and see what happens
[09:36] <duflu> Yeah I would say ordinarily it's a useful feature for plugging in a monitor to wake the system
[09:36] <duflu> If that's what's happening
[09:37] <JamieBennett> OK, auto scan off fixes the wake-ups but is that the right behaviour?
[09:38] <duflu> JamieBennett, that's a kernel question I think
[09:38] <duflu> I've never seen it
[09:38] <duflu> but auto-scanning is also somewhat rare
[09:38] <jamesh> could be doing HDMI CEC?
[09:38] <duflu> That too
[09:38] <JamieBennett> duflu: autoscanning isn't rare is it? Every projector does it
[09:39] <JamieBennett> anyway, I wonder if the multiple wakeups are somehow filling memory and grinding the system to a halt?
[09:40] <duflu> I don't think there are enough wakeups. The original reporter said he had 70GB per day. The machine needs to be awake to cause that much
[09:41] <willcooke> Could be unrelated issues?  A memory leak in each connect/disconnect cycle seems feasible
[09:42] <duflu> willcooke, of disk usage, not memory
[09:43] <JamieBennett> my syslog is only 3.5mb so nothing too huge atm
[09:47] <willcooke> JamieBennett, it will be interesting to see if this helps longer term.  I think jamesh is probably on to something with CEC.  Things like projects probably dont support it, and a lot of computer moniors don't either
[09:48] <JamieBennett> willcooke: It seems to happen each night so I'll leave the autoscan off tonight and see what happens in the morning
[09:48] <willcooke> thanks JamieBennett
[09:49] <jamesh> CEC can allow devices to wake in either direction (e.g. ChromeCasts can wake a television, a TV can wake a game console or bluray player, etc)
[09:50] <jamesh> I'm not sure how to easily get visibility to test it though
[09:55] <willcooke> I wonder if it's Montor -> CEC -> Dock -> ACPI wake up event -> Kernel
[09:55] <willcooke> rather than CEC all the way
[09:55] <willcooke> because yeah, we don't ship libcec or anything like that by default
[09:56] <jamesh> CEC isn't always hooked up to the OS though
[09:56] <jamesh> IIRC Intel's NUCs have CEC wakeup handled by the embedded controller, and you need additional hardware to do more with CEC
[09:57] <jamesh> so a dock could indeed be handling CEC without the OS knowing
[10:01] <willcooke> yeah that's kinda what I was thinking
[10:01] <willcooke> well, lets see if this is the root of the problems and take it from there
[10:02] <duflu> Regardless of the frequency, seeing a stack trace like that is always a bug. So finding a workaround would be good but it's still a bug even if it happens once
[10:22] <willcooke> duflu, in other news - a guy in the Ubuntu UK channel says he's seeing the problem with bluetooth connections on resume from suspend
[10:22] <willcooke> he's got the same hardware as me, so I will test it here
[10:22] <willcooke> this was on cosmic
[10:22] <willcooke> so might be a regression
[10:23] <willcooke> anyway, I will test and log a new bug if needed
[10:23] <duflu> willcooke, I thought we fixed that recently. For audio at least. I think there's an open bug still for mice
[10:24] <willcooke> duflu, ah cool.  I will test with speakers and mice then
[10:24] <duflu> willcooke, mice is bug 1779289
[10:24] <ubot5> bug 1779289 in gnome-bluetooth (Ubuntu) "[regression] bluetooth mouse not reconnected on reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1779289
[10:25] <duflu> Oh, actually, that's not resume. I can't remember where the resume bug is
[10:28] <willcooke> there's this one:
[10:28] <willcooke> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1561474
[10:28] <ubot5> Ubuntu bug 1561474 in linux (Ubuntu) "Bluetooth will be disable after resume from suspend on Xenial" [Medium,Confirmed]
[10:28] <willcooke> which talks about cosmic at the end
[10:35] <duflu> It appears I have lost the bug I was thinking of, and now I'm searching I see several reports but not the one I wanted
[10:35] <duflu> Will need to tidy that up
[10:42] <duflu> willcooke, I forgot to mention the bionic fix for bluez is still in proposed. Are you sure he was on cosmic?
[10:49] <willcooke> duflu, no, you're right - hes on Bionic
[10:51] <duflu> willcooke, ah, so was it audio, mouse, or other?
[10:53] <duflu> AFAICT the bluez reconnect-on-resume fix was not audio-specific. Only a lot of people complained about it regarding audio
[11:00] <willcooke> duflu, sounds like mouse and headphones
[11:00] <willcooke> they're going to try this weekend and let me know
[11:01] <duflu> willcooke, the feedback for audio is that the fix works for everyone (in cosmic and bionic-proposed). I only hope it applies to mice
[11:10] <duflu> Night
=== pstolowski is now known as pstolowski|lunch
=== apw_ is now known as ap
=== ap is now known as Guest79801
=== Guest79801 is now known as apw
=== pstolowski|lunch is now known as pstolowski
=== youpi1 is now known as youpi
[15:40] <juliank> oSoMoN, ricotz: Could one of you investigate the triggers for libreoffice in xenial for bug 1780996, see if there are ones that are not noawait, but changed in later versions, and change them too?
[15:40] <ubot5> bug 1780996 in xpdf (Ubuntu Xenial) "Convert triggers to noawait" [Medium,In progress] https://launchpad.net/bugs/1780996
[15:41] <juliank> Downloading that on my side takes ages, and libreoffice is kind of your thing anyhow
[15:49] <ricotz> juliank, libreoffice-common in xenial contains "interest /@OODIR@/share/extensions"
[15:52] <juliank> ricotz: That's interest-noawait in bionic; unless packages installing files there depend on libreoffice-common, it should be changed there too
[15:52] <ricotz> juliank, you can see the packaging here https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/
[15:53] <juliank> Oh well, they are broken anyhow
[15:53] <juliank> libreoffice-mysql-connector.triggers.in and another one explicitly activate the file trigger too
[15:53] <juliank> that's fixed in bionic
[15:54] <juliank> if those are the only ones shipping files in there, and they depend on libreoffice-common, we can mark the task as wontfix, as that's OK enough
[15:56] <juliank> ok there are more
[15:57] <juliank> It's likely easier to change the trigger and the two activate in the package
[15:57] <juliank> to add -noawait there
[15:57] <juliank> then checking if all packages installing files into the extensions dir depend on libreoffice-common
=== pstolowski is now known as pstolowski|afk
[18:05] <willcooke> night.  It may or may not be coming home.
[18:13] <czajkowski> lol