[05:28] <jibel> good morning
[06:13] <Trevinho> morning jibel
[06:19] <oSoMoN> good morning desktoppers
[06:21] <Trevinho> hi oSoMoN
[06:27] <jibel> hi Trevinho oSoMoN and all
[06:28] <Trevinho> jibel: do you have handy that crash you had on recover from suspend with different monitor settings?
[06:30] <jibel> Trevinho, no, and I don't have a multimontor setup at home
[06:30] <didrocks> good morning
[06:31] <Trevinho> morning didrocks
[06:32] <didrocks> hey Trevinho!
[06:34] <duflu> Hello all
[06:34] <duflu> (and then duflu runs to the post office)
[06:42] <didrocks> hey duflu
[07:25] <duflu> Hmm, I've seen some complaints from people that 'ubuntu-bug' itself crashes and fails to log bugs. Looks like there are a few common reasons: https://errors.ubuntu.com/?package=apport&period=month
[07:26] <didrocks> duflu: 16.04 apparently?
[07:26] <duflu> didrocks, no the top 4 apport crashes are in 17.10 too
[07:27] <didrocks> hum, not what I see… "Last seen" is 16.04 for me
[07:27] <didrocks> oh, not anymore
[07:27] <didrocks> after a refresh
[07:27] <didrocks> cache? :/
[07:33] <krashekspress> hitting logout/shutdown in gnome-shell topbar most of times results in 10-25 seconds freeze of DE, is there any way I can figure out why is it happening?
[07:35] <duflu> krashekspress, 25 seconds happens to be the default dbus timeout. You can usually track it down looking at the log by running 'journalctl'
[07:37] <krashekspress> duflu, can you take a look ->> https://pastebin.com/WJ0Tn8Ds
[07:48] <duflu> krashekspress, please attach that log in a new bug here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+filebug
[07:49] <andyrock> good morning!
[07:50] <duflu> Morning andyrock
[07:54] <willcooke> ahoy
[07:54] <didrocks> hey willcooke !
[07:54] <didrocks> happy post-release day :)
[07:54] <willcooke> :)
[07:54] <krashekspress> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1725163
[07:55]  * didrocks is preparing the SRU for our ATI revert fix
[07:55] <willcooke> didrocks, is the root cause fixed now?
[07:55] <didrocks> willcooke: duflu: interestingly, I got other reports like amano for who the revert fixed it for him as well. I think it really fixed for "all users that were fallbacked to Xorg due to driver/card", could have been huge
[07:56] <duflu> didrocks, cool, thanks
[07:56] <didrocks> willcooke: yep, upstream, I prepared some packages in a ppa (mutter/gnome-shell) and I got 3 confirmations of their system keeps working
[07:56] <willcooke> krashekspress, out of interest, can you try and open cheese and see if you have a similar lag there?
[07:56] <willcooke> didrocks, neat, thanks
[07:59] <krashekspress> willcooke, lol, cheese is starting 25 seconds Č=
[07:59] <krashekspress> :)
[08:00] <duflu> 25 seconds
[08:00] <duflu> Always 25 seconds
[08:00] <duflu> dbus FTW
[08:00] <duflu> where W is delayed by 25 seconds
[08:01] <krashekspress> that was wild guess, just tested with stopwatch, 33 seconds exactly
[08:01] <willcooke> so my guess is that it's related to: https://bugzilla.gnome.org/show_bug.cgi?id=783789
[08:02] <willcooke> which is related to: https://bugzilla.gnome.org/show_bug.cgi?id=782627
[08:02] <andyrock> nice that there is already a fix for the most reported bug
[08:02] <andyrock> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1720400
[08:02] <andyrock> :D
[08:03] <krashekspress> I also have logitech camera
[08:03] <krashekspress> so theoretically if I disable camera, problem should go away
[08:04] <willcooke> krashekspress, I think the camera is a red herring, I think, as duflu said, it's probably a dbus issue
[08:04] <willcooke> but I think the root cause of the camera, and the users panel, and the slow shutdown is all the same
[08:05] <krashekspress> just for sanity I unpluged the camera, cheese starts instantly, shutdown/logout works also instantly
[08:06] <krashekspress> can I do anything?
[08:06] <didrocks> how come the camera can make gnome-session-binary not responding on dbus…
[08:06] <willcooke> krashekspress, good detective skills :)  Could you comment to that effect on the bug please?
[08:06] <didrocks> apart if it the camera is spamming dbus
[08:06] <didrocks> and preventing any other traffic…
[08:07] <jibel> willcooke, not sure it is a red herring. without an external webcam, cheese starts in in 4s, with the external camera it starts in 34s
[08:08] <willcooke> fair point
[08:08] <didrocks> dbus-monitor --session
[08:08] <didrocks> do you have a lot more traffic when you plug those external webcams?
[08:08] <willcooke> krashekspress, ^
[08:09] <jibel> I don't
[08:09] <didrocks> (gdbus monitor doesn't seem to allow global monitoring as the retired dbus-monitor)
[08:09] <didrocks> hum, so not that
[08:09] <willcooke> I can reproduce on my test laptop, but the webcam is not pluggable
[08:10] <willcooke> the cheese issue at least
[08:10] <duflu> More likely the app at the other end is hung or crashed for krashekspress ...
[08:10] <duflu> Oct 20 09:35:59 MegaHulk at-spi2-registr[11456]: Failed to send session response Timeout was reached
[08:10] <duflu> Oct 20 09:36:23 MegaHulk gsd-power[11521]: Failed to acquire idle monitor proxy: Timeout was reached
[08:10] <didrocks> willcooke: you probably have an USB internal webcam
[08:10] <didrocks> duflu: well, if gnome-session-binary is hung/crashed, you won't be able to do a lot :p
[08:10] <didrocks> if crash -> session is closed
[08:10] <duflu> Maybe we need to look for .crash files instead of a hang
[08:10] <didrocks> if hung -> maybe??? but how can it unblocks when unplugging the camera
[08:11] <jibel> didrocks, http://paste.ubuntu.com/25777611/ this is the dubs traffic for unplug/plug the camera, launch cheese and wait until it starts
[08:11] <didrocks> ahhh, inhibit signal
[08:12] <didrocks> jibel: hum, where is the camera traffic? can you only take that one
[08:12] <didrocks> (without cheese)
[08:12] <didrocks>    string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.SessionManager'"
[08:12] <didrocks> method return time=1508486997.823203 sender=org.freedesktop.DBus -> destination=:1.122 serial=13 reply_serial=11
[08:12] <jibel> didrocks, what do you mean?
[08:13] <didrocks> -> hum, NameOwnerChanged…
[08:13] <jibel> didrocks, just plug/unplug?
[08:13] <didrocks> jibel: just print the traffic with plug/unplug, without cheese running
[08:13] <didrocks> yes
[08:13] <jibel> k
[08:14] <jibel> http://paste.ubuntu.com/25777619/
[08:14]  * didrocks tries something which may crash my session, brb if that's the case
[08:14] <krashekspress> updated big
[08:14] <jibel> didrocks, ^
[08:14] <krashekspress> *bug
[08:14] <krashekspress> hahaha
[08:14] <willcooke> thanks krashekspress
[08:14] <jibel> it crashed :)
[08:14] <willcooke> lol
[08:14] <krashekspress> I should be working, but this is fun :)
[08:15] <didrocks> ok, confirming, gnome-session launches gnome-session-binary, but even if this latter is killed (or it crashed), your session terminates
[08:15] <didrocks> so, it's not a crash of that component at least
[08:15] <didrocks> jibel: ok, no traffic for inhibiting or towards gnome-session-binary
[08:17] <jibel> interested by an strace of cheese?
[08:18] <duflu> didrocks, FYI those MUTTER env vars actually cause the interesting logging to happen in journalctl. The one in /tmp is not useful
[08:18] <didrocks> jibel: sure (I need to jump on the SRU though), but also, mind trying "systemd-inhibit echo foo"
[08:18] <didrocks> duflu: well, they could for some case, but yeah, agreed
[08:18] <didrocks> jibel: and tell me if "foo" is printed right away
[08:19] <duflu> also, you need to remember to look for gdm3 messages before gnome-shell. Sincew gdm3 is also a mutter shell
[08:19] <didrocks> or there is a delay
[08:19] <didrocks> duflu: hum, gdm3 is launching g-s, no?
[08:19] <duflu> didrocks, yes. But gdm3 is also a standalone "shell" of sorts, using mutter
[08:20] <jibel> didrocks, it's printed immediately
[08:20] <duflu> Call it a DM then. I don't mind
[08:20] <didrocks> duflu: interesting, I didn't see this part of code, I only looked at gdm3 launching gnome-session, which launch gnome-shell as the gdm user in the "gdm" mode
[08:20] <jibel> didrocks, http://people.canonical.com/~j-lallement/junk/cheese.strace
[08:20] <didrocks> jibel: which line is it blocking during the delay?
[08:21] <duflu> didrocks, I realize when I was doing the font work... it instantly improved the login screen too
[08:21] <didrocks> great!
[08:21] <vithiri> Hmm. We've still got a task bar at ubuntu.com today. :)
[08:21] <duflu> (but only because Ubuntu introduces more sane defaults for hinting and subpixel)
[08:21] <willcooke> vithiri, yeah :(  working on getting that fixed
[08:22] <vithiri> willcooke: Ah, sounds great!
[08:28] <dupondje> mmm. Upgraded to 17.10, but seems like there is some minor bug that causes me to be unable to save OpenVPN settings in gnome-control-center. When running in verbose mode it gives me 'Invalid setting IPv4'. Works fine with nm-connection-editor. I file a bug against gnome-control-center right?
[08:29] <andyrock> dupondje: yes please. In case we can always change the target project later on
[08:31] <jibel> didrocks, nothing is blocking it's repeating the same sequence over and over again
[08:31] <jibel> didrocks, something like http://paste.ubuntu.com/25777697/
[08:31] <didrocks> jbicha: I'm removing your restore dep commit in gnome-shell, it doesn't reference any bug, so not suitable for a SRU
[08:31] <jibel> minus the inotify call
[08:31] <didrocks> jibel: hum, I guess it has some retry logic
[08:32] <didrocks> jbicha: please restore it with the correct bug # for a later SRU (don't want to block current SRU on this)
[08:32] <didrocks> jibel: have you tried "systemd-inhibit echo foo", does it blocks as well?
[08:32] <didrocks> (if so, could be an easier test case)
[08:33] <jibel> didrocks, no it doesn't block
[08:34] <didrocks> argh :/
[08:34] <jibel> didrocks, sequences are not identical, it tries different format
[08:34] <jibel> fmt.pix={width=1280, height=800 .... changes between each call
[08:35] <jibel> maybe the external webcam has more capabilities than the internal one and it takes much longer to check them
[08:35] <jibel> just a guess
[08:35] <jibel> doesn't sound dbus relaed to m
[08:35] <jibel> related*
[08:35] <didrocks> could be… so we would have 2 different issues
[09:22] <Guest34021> Hello, sabdfl is Mark Shuttleworth ?
[09:26] <oSoMoN> https://askubuntu.com/questions/1020/who-is-sabdfl-what-does-he-do
[09:28] <jibel> downgraded the kernel then cheese and no difference
[09:29] <jibel> more than 30s to launch with an external webcam
[09:51] <doko> didrocks, are there any transitions you would like to start with for b?
[09:52] <didrocks> doko: nothing that I know of at least. gjs was the big one and already in a
[10:23] <jibel> I think the cheese issue has nothing to do the other slowness. It's just that cheese spends more time probing the webcam for its capabilities and the external camera support 36 formats against 12 for the internal
[10:29] <willcooke> that probing shouldn't take 20+ seconds though
[10:30] <jibel> indeed, there is definitely room for optimization
[10:31] <jibel> could be something in gstreamer
[10:31] <willcooke> But then why would disconnecting the web cam also make shutting down quicker
[10:32] <willcooke> krashekspress_, when you get a moment, can you open the users panel in control center with and without the camera attached?
[10:33] <jibel> no idea, shutting down is fast for me with or without the webcam
[10:33] <jibel> just cheese is slow when the webcam is attached
[10:33] <willcooke> lemme try and rmmode the webcam driver and see if that fixes opening users for me
[10:34] <krashekspress_> willcooke, with camera 12sec, without camera instant
[10:35] <willcooke> Kamilion, thanks
[10:35] <willcooke> jibel, yeah, rmmod uvcvideo and users opens instantly for me too
[10:35] <willcooke> very very odd
[10:35] <jibel> strange
[10:35] <krashekspress_> that is one strange correlation
[10:36] <willcooke> :)
[10:36] <krashekspress_> smells like spaghetti ;)
[10:38] <jibel> let me try on another machine
[10:40] <willcooke> vithiri, website fixed
[10:40] <willcooke> desktoppers ^
[10:53] <jibel> willcooke, ah I've the problem on my other machine
[10:54] <jibel> with the webcam attached the accounts panel takes a while to open
[10:55] <krashekspress_> funny thing, I had this problem on 17.04 (and probably 16.10, can't remember), but it wasn't reproducable 100% of the time
[10:55] <krashekspress_> now it works like a feature 10/10 :)
[10:55] <jibel> krashekspress_, and you were running unity or gnome-shell?
[10:55] <krashekspress_> that problem was only on gnome-shell
[10:55] <krashekspress_> doesn't matter what distro
[10:57] <krashekspress_> well only other distro I tried on desktop with gnome-shell was Arch
[10:57] <jibel> I'm wondering if the account panel is using gstream for the mugshot
[10:57] <krashekspress_> and it was suffering from same behavior
[10:57] <willcooke> jibel, oooooh, interesting
[10:58] <krashekspress_> one more thing, I think it didn't affect account panel on old settings, but I can't be sure
[10:58] <jibel> which would probe the webcam and that would be the same problem than cheese startup time
[10:58] <krashekspress_> old settings from 3.24 (i think)
[11:02] <ogra_> jibel, it should really only init the cam when actullay taking the mugshot though ...
[11:02] <ogra_> *actually
[11:04] <popey> Hm, in 17.10 under wayland, can someone (in firefox) go to http://snapcraft.io/atom and click the install button and tell me what happens?
[11:04] <jibel> willcooke, that's a win
[11:04] <jibel> 0:00:00.952296320 ^[[333m 2276^[[00m 0x562201c56720 ^[[37mDEBUG  ^[[00m ^[[00m                v4l2 gstv4l2object.c:2577:gst_v4l2_object_probe_caps_for_format:<v4l2deviceprovider0>^[[00m Enumerating frame sizes for YUYV
[11:04] <jibel> 0:00:06.381870733 ^[[333m 2276^[[00m 0x562201c56720 ^[[37mDEBUG  ^[[00m ^[[00m                v4l2 gstv4l2object.c:2602:gst_v4l2_object_probe_caps_for_format:<v4l2deviceprovider0>^[[00m done iterating discrete frame sizes
[11:04] <jibel> 6s to enumerate the frame sizes with the camera attached
[11:04] <popey> for me, firefox says "The address wasn't understood" (the snap:// url scheme seems broken
[11:04] <popey> (just want to make sure it's not just my pc before I file a bug)
[11:04] <krashekspress_> if I can offtopic a bit, why there is no suspend button? Is there some other option I can use when leaving pc for few hours? shutdown is not an option :)
[11:05] <krashekspress_> popey, for me too
[11:05] <popey> krashekspress_: hold ALT and press the indicator area, shutdown becomes suspend (pause icon)
[11:05] <jibel> krashekspress_, willcooke what is the bug #?
[11:05] <willcooke> popey, confirmed. But xdg-open is working, which is odd.  Please log and ping me the #
[11:05] <popey> kk
[11:05] <krashekspress_> jibel, 1725163
[11:05] <popey> willcooke: file against what? gnome-software?
[11:05] <jibel> krashekspress_, thx
[11:05] <willcooke> popey, Firefox I think
[11:05] <popey> kk
[11:06] <jibel> krashekspress_, yeah but that's for the shutdown not the user panel
[11:06] <krashekspress_> popey, thanks, now I wonder what was wrong with just adding one more icon :)
[11:06] <jibel> I can reproduce the user panel issue but not the shutdown
[11:06] <jibel> maybe it's different
[11:06] <popey> krashekspress_: (I agree)
[11:07] <popey> Pretty sure elementaryOS add the icon in there. But I never click it, I just slam the lid of the laptop shut, so doesn't affect me so much :)
[11:07] <willcooke> popey, FYI Chromium works
[11:07] <krashekspress_> jibel, 783789 ?
[11:07] <popey> k
[11:10] <jibel> krashekspress_, thanks
[11:12] <krashekspress_> popey, haha, slamming is also not an option on desktop, well maybe in certain moments
[11:15] <popey> willcooke: http://pad.lv/1725238
[11:16] <willcooke> popey, ta, assigned
[11:34] <oSoMoN> willcooke, I'll take a look
[11:34] <willcooke> thanks oSoMoN, this used to work, so I think it's a change in the new ffox
[11:59] <vithiri> willcooke: Yes, I noticed that from my phone earlier when visiting it. Awesome. :)
[12:00] <didrocks> vithiri: I think you can see that https://www.ubuntu.com/ has now the dock in the correct place! :)
[12:07] <didrocks> willcooke: hum, the software center isn't the correct icon, and there is no "apps" button at the bottom (nor it's our default launchers) ^
[12:08] <didrocks> I think they cut the button and mess with the sessions :p
[12:08] <willcooke> good spot didrocks
[12:12] <willcooke> poked on web-team
[12:14] <mdeslaur> if only there was a way to actually take a screenshot on the real product! ;)
[12:14] <willcooke> :)
[12:15] <didrocks> they probably tried with shutter on wayland ;)
[12:16] <Guest34021> Hello
[12:17] <Guest34021> What is the codename for Ubuntu 18.04LTS ?
[12:20] <mgedmin> not decided yet afaik
[12:24] <Guest34021> When will it be decided?
[12:29] <ogra_> once mark has an epiphany
[12:31] <Guest34021> ok
[13:17] <oSoMoN> chrisccoulson, are you looking into distro-patching the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1382323 ?
[14:51] <kenvandine> popey, do you have the mojo to trigger a rebuild of the corebird snap?
[14:51] <oSoMoN> chromium snap promoted from candidate to stable, I'll write about it shortly
[14:51] <kenvandine> popey, i want it to pick up the desktop helpers fix so it works on fedora :)
[14:51] <kenvandine> oSoMoN, awesome!
[14:51] <oSoMoN> and launching a new build with the latest upstream stable version
[14:51] <kenvandine> oSoMoN, ah... time to repeat the process :)
[14:52] <popey> kenvandine: good question!
[14:52] <kenvandine> it's snapcrafters, so i think you do :)
[14:52] <kenvandine> oSoMoN, have you tested your chromium snap on fedora?
[14:53] <popey> kenvandine: https://github.com/snapcrafters/corebird/blob/master/snap/snapcraft.yaml
[14:54] <popey> thats the yaml, is it actually using the desktop launcher?
[14:54] <kenvandine> yes
[14:54] <kenvandine>     after: [desktop-gnome-platform]
[14:54] <kenvandine> so it should work on fedora after a rebuild
[14:54] <popey> ok
[14:54] <popey> the only way I can do that is change the yaml
[14:55] <popey> we don't have a manual trigger option
[14:55] <kenvandine> that's annoying :)
[14:55] <kenvandine> but a no change commit should work right?
[14:55] <popey> yes, I'll try
[14:55] <kenvandine> oh wait though
[14:55] <kenvandine> i might need you to change something in it
[14:55] <kenvandine>  :)
[14:55] <popey> hah
[14:55] <popey> you can :D
[14:55] <kenvandine> it isn't autoconnecting and it should
[14:55] <kenvandine> oh... i can?
[14:56] <popey> I'll gladly accept a PR :D
[14:56] <kenvandine> great
[14:56] <kenvandine> i'll do that
[14:57] <willcooke> thanks oSoMoN
[14:59]  * kenvandine tests corebird fix
[15:01] <oSoMoN> https://plus.google.com/+OlivierTilloy/posts/fC3SUKPZm4w
[15:13] <oSoMoN> jbicha, thanks for verifying the SRU for bug #1718446
[15:14] <oSoMoN> do I need to ping the release team to have the update promoted from -proposed to -updates?
[15:15] <kenvandine> oSoMoN, just tested your chromium snap on fedora, seems to work fine
[15:15] <jbicha> yes, usual procedure is to wait 7 days before SRUs go to -updates but Release Team grants exceptions some times
[15:15] <kenvandine> oSoMoN, but the fonts look terrible.  Not on the rendered sites, but the UI fonts
[15:16] <kenvandine> menus, address bar, etc
[15:17] <jbicha> kenvandine: what Fedora version?
[15:17] <kenvandine> 26
[15:19] <popey> oSoMoN: have you tested this on nvidia hardware?
[15:20] <oSoMoN> popey, no, I still don't own nvidia hw
[15:20] <popey> oSoMoN: its broken
[15:20] <oSoMoN> darn
[15:20] <oSoMoN> popey, how much broken?
[15:20] <popey> wont start, grey screen
[15:20] <oSoMoN> kenvandine, right, most likely because the default system font on fedora is not included in the snap
[15:21] <oSoMoN> popey, that's not a regression compared to the previous stable version of the snap however?
[15:21] <oSoMoN> popey, I need to seriously look into that issue (and try to get my hands on nvidia hw)
[15:22] <popey> indeed, revision 9 is equally broken
[15:22] <oSoMoN> kenvandine, I've added a solus-specific font to the snap to get the UI to display correctly on that distro, I could probably do the same for fedora, but this doesn't really scale, what we need is the work jam_esh did on using system-wide fonts in snapd to be released
[15:23] <kenvandine> yeah
[15:23] <kenvandine> it's fine :)
[15:24] <oSoMoN> popey, not much comfort, but at least it's not a regression so no good reason to revert
[15:24] <jbicha> it makes sense to add Cantarell as a workaround since nearly all GNOME distros default to that
[15:24] <popey> Right, but this wouldn't fly with a deb
[15:24] <oSoMoN> agreed
[15:25] <oSoMoN> kenvandine, can you confirm that the default UI font on fedora is cantarell? I can add it to the snap for the next iteration
[15:29] <kenvandine> oSoMoN, checking
[15:31] <didrocks> yeah, Cantarell is default fedora font
[15:31] <didrocks> (actually, default GNOME font, which is now default fedora one)
[15:31] <oSoMoN> ack, thanks
[15:31] <oSoMoN> adding it to the snap
[15:31] <popey> Are we adding every distro default font? :)
[15:31] <kenvandine> it is
[15:32] <oSoMoN> popey, only distros we care about I guess :)
[15:33] <oSoMoN> I mean I won't go over all supported distros and add their fonts one by one, but if I get a report and it's easy enough to fix by simply adding a stage package, I don't mind
[15:34] <oSoMoN> the solus font was a fun one, because it's not available as a deb, so I'm fetching the solus package and unpacking it in the right place
[15:34] <oSoMoN> good that font files are architecture-independent :)
[15:35]  * popey wonders what font Pop!?!?!_OS uses.
[15:35] <kenvandine> i've added some of those to the gnome platform snap, so not everyone needs too
[15:36] <oSoMoN> the chromium snap is not using the gnome platform snap though
[15:36] <kenvandine> right
[15:38] <oSoMoN> popey, quick question re-nvidia brokenness: does it work any better with a more recent snapd (i.e. with the core snap from the candidate or edge channel) by any chance?
[15:39] <kenvandine> so confusing... corebird still won't autoconnect to the platform snap
[15:39] <kenvandine> so weird
[15:41] <kenvandine> popey, https://github.com/snapcrafters/corebird/pull/14
[15:41] <kenvandine> maybe installing it from the store will work better :)
[15:42]  * kenvandine is out of ideas
[15:43] <popey> merged
[15:43] <kenvandine> popey, thx
[15:43] <kenvandine> https://github.com/system76/pop-gtk-theme#recommendations
[15:43] <kenvandine> their fonts are Fira and Roboto
[15:49] <oSoMoN> fonts-firacode appears to be monospace, so I guess only roboto would be needed to get the UI to display properly?
[15:51] <didrocks> well, parts of some apps UI could force monospace
[15:54] <oSoMoN> I don't think chromium does, but I can add firacode just for safety, the size overhead will be minimal compared to the CJK fonts we ship already
[15:54] <oSoMoN> Installed-Size: 1 559 kB
[15:54] <oSoMoN> should be fine
[15:55] <didrocks> yeah, I don't know what it's using if some webfonts are not available and trying to use monospace, so better to be safe, as you told, the size isn't relevant
[16:05] <popey> kenvandine: corebird finished building and should be in edge
[16:06] <oSoMoN> added, the next automatic build will have cantarell, fira and roboto
[16:06] <oSoMoN> the chromium snap is quickly becoming a fonts-collection snap
[16:16] <willcooke> oSoMoN, once jamesh's font fixes land in snapd that should go away \o/
[16:30]  * oSoMoN EOW, have a great week-end everyone!
[16:35] <kenvandine> oSoMoN, have a great weekend
[16:55] <willcooke> right, I'm calling it a day as well.  Night all
[16:55] <willcooke> have a great weekend, lots to do next week ;)
[18:57] <mhall119> congrats on the big release everyone!