[06:06] <oSoMoN> good morning desktoppers
[06:07] <duflu> Morning oSoMoN
[06:30] <oSoMoN> hey duflu
[06:32] <jibel> hi oSoMoN, duflu and everyone
[06:34] <duflu> jamesh, is that problematic version 7.5 (reverted from updates to proposed) going to get released again in 7.6?
[06:34] <duflu> The code hasn't changed
[06:34] <duflu> https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/log/?h=ubuntu-bionic
[06:34] <duflu> Morning jibel
[06:34] <jamesh> duflu: it will migrate back to updates with the new snapd-glib
[06:34] <duflu> jamesh, good then :)
[06:34] <jamesh> no need for a new release
[06:35] <duflu> I was worried about having to rewrite the history of 7.6 before it goes out
[06:36] <jamesh> I don't think anyone has discovered any problems with the policy module: it was just the dependency issue with libsnapd-glib1 pulling in snapd
[06:44] <duflu> 👍
[07:11] <oSoMoN> salut jibel
[07:11] <oSoMoN> hey jamesh
[07:32] <marcustomlinson> duflu: did you determine that libreoffice was actually at fault here? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1856702
[07:35] <marcustomlinson> sounded more like a general rendering issue than specifically libreoffice. curious if you knew something more about it
[07:45] <duflu> marcustomlinson, no just most likely LO if other apps are unaffected
[07:45] <duflu> Back later...
[08:38] <marcustomlinson> morning desktoppers
[08:40] <duflu> Oh hi marcustomlinson :)
[08:40] <marcustomlinson> I'm really awake now ;)
[08:55] <duflu> marcustomlinson, I tidied up bug 1856702 for you.
[08:55] <marcustomlinson> oh excellent thanks!
[09:02] <Laney> o/
[09:09] <duflu>                       \o
[10:03] <oSoMoN> good morning marcustomlinson, Laney
[10:32] <popey> Good morning
[10:33] <popey> if gnome-shell is consuming 3.0g RES in top, should I be concerned?
[10:33] <popey> I mean, i have 32GB RAM, but this seems excessive
[10:38] <duflu> Morning popey, yes gigabytes is a concern but only if it is RES or RSS
[10:38] <duflu> We have bug 1856516 about that just this week
[10:38] <popey> last time this happened you asked me to gather vmm data
[10:38] <popey> https://paste.ubuntu.com/p/HKWmz7gKhx/
[10:39] <popey> I'm on x
[10:39] <popey> i have a cronjob I just started which gathers the data you asked for in another bug report
[10:40] <duflu> popey that history shows the RSS at 3.2GB the whole time. Thanks, but I am not sure we need more info other than that proof of a bug. Maybe just ensure you don't have any non-Ubuntu extensions
[10:40] <popey> is there a way to list my active extensions easily?
[10:41] <duflu> I'm not sure if you want an *accurate* list. I rely on the automatic attachments to peoples' bug reports
[10:41] <duflu> popey, also they have to be uninstalled. Anything installed but inactive can still hurt
[10:42] <duflu> Because bugs
[10:42] <popey> hm, okay. I don't actually think I have any, but i cant be 100% certain
[10:42] <popey> indeed
[10:42] <popey> I'll file a dummy bug in ubuntu-bug against gnome-shell and throw it away, that'll gather it?
[10:42] <duflu> popey, yes I was just about to ask for that. It's more valid than "dummy" :)
[10:43] <popey> hah
[10:43] <popey> ok, while I do that, check this out. another bug I dunno if it has been filed...
[10:43] <popey> https://youtu.be/869e9YwW0vw
[10:44] <duflu> Whoa, youtube within youtube. Yeah I am looking at stutters/freezes again now
[10:45] <duflu> Unless strace or something in the journalctl -f shows a possible cause then I am not sure what to suggest right now
[10:45] <popey> ok
[10:46] <duflu> IO% is an interesting angle though
[10:51] <duflu> Got to run
[11:19] <JanC> gnome-shell always keeps growing the longer you run it, unfortunately
[11:22] <popey> I tend to be averse to rebooting, I suspend my laptop all the time and leave it running all day and night often.
[11:22] <popey> Which I don't think is unreasonable behaviour :)
[11:23] <JanC> you can always try restarting gnome-shell, that should get you some memory back
[11:23] <popey> Good point.
[11:26] <JanC> gnome-shell is at 4.7 GiB here now, so I guess I should restart it too...  :P
[11:27] <JanC> (desktop that is running pretty much 24/7)
[11:28] <JanC> with an uptime of a couple of weeks...
[11:28] <popey> do you have a bunch of extensions out of interest?
[11:30] <JanC> I have some, but I tested for a couple weeks 1 or 2 releases ago where I only had the default ones, and it had the same issues
[11:31] <JanC> compiz also had similar issues, of course...
[12:00] <RikMills> I seem to recall a bug about ubiquity detecting hardware stage hanging for a long while with 100% CPU? Does anyway have a link?
[16:03] <hellsworth> good morning desktopers
[16:21] <oSoMoN> good morning hellsworth
[16:21] <hellsworth> hi!
[16:21] <hellsworth> i hope your day is going well :)
[16:39] <oSoMoN> hellsworth, it is, thanks! how are you?
[16:43] <hellsworth> oh i'm great thanks!
[17:44] <marcustomlinson> jdstrand: hey, I'm new to this sort of issue, is there something I need to do for this? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1849680
[17:52] <jdstrand> marcustomlinson: I've not looked at the packaging much before just now, but it looks like debian/rules references dh_apparmor and there is setup via sysui/desktop/share/apparmor.sh. the basic process would be to patch to add accesses to the profiles. best practice would be to attach that to the bug and a member of the security team can review it
[17:54] <marcustomlinson> okidokes
[17:54] <marcustomlinson> thanks
[17:55] <jdstrand> marcustomlinson: if you need help with the rules, that's fine too
[17:55] <jdstrand> marcustomlinson: /sys/fs/cgroup/{,**} r, would be one
[17:56] <jdstrand> marcustomlinson: using the dri-common abstraction would be another
[17:58] <jdstrand> marcustomlinson: using the mesa abstraction for the mesa_shader_cache write is probably fine
[17:59] <jdstrand> marcustomlinson: you can test that the profile compiles with 'apparmor_parser -QTK profile' (no root needed) and can load into the kernel with 'apparmor_parser -r profile' (you probably knew that :)
[18:00] <jdstrand> marcustomlinson: @{PROC]/@{pid}/cgroup r,
[18:00] <jdstrand> marcustomlinson: @{PROC]/@{pid}/mountinfo r,
[18:00] <jdstrand> marcustomlinson: I think that all together that'll get rid of a lot of noise
[18:09] <marcustomlinson> jdstrand: that helps a lot thanks!