[00:53] <mdeslaur> lol
[00:53] <mdeslaur> <mdeslaur> joemcmanus: lol
[00:54] <mdeslaur> whoops, paste fail
[00:54] <mdeslaur> lol: https://twitter.com/b6n/status/1103082019632799744
[01:01]  * tsimonq2 follows mdeslaur on Twitter
[05:15] <duflu> Oh, disco-proposed just got kernel 5.0
[07:12] <didrocks> good morning
[07:14] <duflu> Morning didrocks and seb128
[07:15] <jibel> Hi all
[07:16] <duflu> Hi jibel
[07:19] <didrocks> hey duflu, salut jibel
[07:33] <jbicha> clobrano: the pager indicators on the right side of the Activities Overview are missing in disco with disco's Yaru theme. Is that already fixed by your 3.31 shell theme rebase?
[07:34] <jbicha> (I mean with gnome-shell 3.31.90)
[07:40] <clobrano> Hey jbicha, yes it should be this one https://github.com/ubuntu/yaru/pull/1205
[07:40] <gitbot> ubuntu issue (Pull request) 1205 in yaru "Replace page-indicator icons with SCSS /copied from upstream shell theme" [Closed]
[07:42] <jbicha> thanks
[08:04] <oSoMoN> good morning desktoppers
[08:05] <duflu> Morning oSoMoN
[08:05] <oSoMoN> hey duflu
[08:09] <jibel> Today's disco is installing fine and I promoted image 20190305.1
[08:10] <jibel> I'm now looking why images are not promoted automatically
[08:18] <didrocks> jibel: the bug which was shallowed by the other bug now :)
[08:18] <didrocks> hey oSoMoN
[08:19] <oSoMoN> salut didrocks
[08:24] <seb128> hey duflu didrocks jibel jbicha oSoMoN clobrano desktopers
[08:25] <seb128> how are you today?
[08:26] <didrocks> hey seb128, the weather is grey and windy here, you?
[08:26] <seb128> same, quite windy today and a bit of rain
[08:31] <duflu> seb128, is the 19.04 board meant to have 2 different labels "GNOME Shell" that are different colours?
[08:31] <seb128> duflu, probably not, likely someone who overlooked that we had one and created it again
[08:32] <duflu> seb128, yeah the old one drifted off the first screen and into "Show more labels"
[08:33] <seb128> that's probably why
[08:33] <oSoMoN> salut seb128
[08:33] <duflu> seb128, shall I merge them?
[08:33] <seb128> duflu, yes please
[08:33] <seb128> oSoMoN, lut, en forme ?
[08:33] <oSoMoN> seb128, ça va, et toi?
[08:34] <seb128> encore un fond de gorge qui gratte et un peu fatigué mais sinon ça va
[08:35] <duflu> Done
[08:35] <seb128> thx
[08:36] <clobrano> Hey seb128 o/, good morning everyone
[08:36] <didrocks> morning clobrano
[08:37] <duflu> Hi clobrano
[08:52] <willcooke> Good morning|afternoon all
[08:54] <didrocks> hey willcooke
[08:55] <willcooke> how goes didrocks?
[08:57] <didrocks> willcooke: weather isn't as nice as the previous days, otherwise, good, you?
[08:57] <duflu> Morning willcooke
[08:58] <willcooke> much the same :)  It's been raining a lot and the heating is back on
[08:58] <willcooke> hi duflu
[08:58] <didrocks> waow, we are not as far as putting heating back on
[08:58] <duflu> Rain tomorrow here (it's strangely exciting)
[08:59] <didrocks> :)
[08:59] <willcooke> ha
[09:01] <Laney> yo
[09:02] <seb128> hey willcooke, Laney
[09:02] <seb128> how is u.k today?
[09:02] <willcooke> morning seb128 Laney
[09:02] <didrocks> hey Laney
[09:02] <Laney> hey seb128 willcooke didrocks, what's up?
[09:03] <Laney> looks grey today
[09:03] <didrocks> not much, you?
[09:03] <didrocks> yeah
[09:03] <seb128> windy, raining, summer moved away for now
[09:08] <duflu> 'lo Laney
[09:09] <willcooke> seb128, I'm thinking that I will move the "drop facebook from xenial" card to next cycle.  OK with you?
[09:09] <willcooke> https://trello.com/c/HgvVcavR
[09:10] <duflu> Is disco going to get gnome-control-center GUI support for fractional scaling in time?
[09:10] <willcooke> duflu, TBD.  I hope yes, but we will do some testing next week to decide.
[09:57] <seb128> willcooke, sorry, was in a call, yes moved the xenial/facebook one souns good
[10:10] <willcooke> moved
[10:12] <willcooke> oh, I managed to send that rls bugs email to the desktop mailing instead of the group in my contacts.  Sorry about that.  No harm done though I think.
[10:30] <seb128> indeed not, all those bugs are publics
[10:31] <willcooke> I guess it will go to the community hub anyway at some point, so yeah, fine
[10:31] <willcooke> I started looking at scraping the rls bug pages yesterday, the bugs are all in a JS JSON object, so I would have to download the HTML and the parse it, fine the JS, fine the variable, and trim it, and then parse it.
[10:32] <willcooke> That seems wrong
[10:32] <willcooke> Can someone link me to the code that generates those pages?
[10:32] <willcooke> I could just run a report myself and use the results there instead of screen scraping
[10:34] <willcooke> s/fine/find
[10:39] <seb128> willcooke, I don't know/can't find it, bdmurray probably knows though
[10:39] <willcooke> seb128, ack, I'll ask him.  Thanks
[10:39] <seb128> or maybe Laney
[10:41] <Laney> afraid not
[10:43] <Laney> would seem sensible to coordinate with Brian on any required changes, e.g. saving that json to a file and having the webpage load it from there so it's downloadable for others too
[10:44] <willcooke> roger roger.  I'll speak to Bryan
[10:47] <seb128> cool
[10:47] <seb128> jbicha, you saw that your appstream sync fails to build?
[10:47] <Laney> I found https://code.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk but I'm not sure the rls ones are in there
[10:53]  * willcooke looks
[10:54] <willcooke> Oooh
[10:54] <willcooke> https://bazaar.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk/view/head:/team-bug-notifier.py
[11:25] <seb128> tseliot, you saw that your ubuntu-drivers-common update failed to build?
[11:26] <tseliot> seb128: yes, and I'm working on it
[11:26] <seb128> k, thx :)
[11:51] <seb128> willcooke, Laney, others: any opinion on dropping the restore_filechooser_typeaheadfind change we have on gtk? it's somewhat an heated topic, but the patch is buggy atm (it creates focus issues with the search entry) and typeahead was dropped from nautilus as well, I think we should try without it and see what's the feedback is (so we have time to revisit before the LTS if needed)
[11:52] <didrocks> as we have tracker now, I would +1
[11:52] <willcooke> ha, I was just looking at that too
[11:53] <Laney> yes that is fine by me
[11:53] <willcooke> I didnt know that the search box was so broken
[11:53] <willcooke> Having just tested it, yeah, that sucks
[11:53] <willcooke> I guess I just always used type ahead
[11:53] <willcooke> +1
[11:53] <seb128> reading https://gitlab.gnome.org/GNOME/gtk/issues/839 makes me think people still care about it
[11:54] <gitbot> GNOME issue 839 in gtk "FileChooser: Allow disabling recursive search" [5. Filechooser, Bugzilla, Opened]
[11:54] <seb128> but let's experiment and see how it feels :)
[11:54] <seb128> thx didrocks Laney willcooke
[11:54] <willcooke> thanks seb128
[11:54] <seb128> if we end up restoring the patch we should fix the "steal focus from the search entry" problem
[11:54] <willcooke> yeah
[11:55] <seb128> in fact we should probably fix that anyway since it gets regular complains from LTS users
[11:55] <willcooke> That would be good
[11:56] <willcooke> seb128, you want me to open a bug about fixing type ahead in B>?
[11:56] <seb128> willcooke, no, that's bug #1592177
[11:56] <ubot5> bug 1592177 in gtk+3.0 (Ubuntu) "Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour)" [Undecided,Confirmed] https://launchpad.net/bugs/1592177
[11:56] <willcooke> ah, I see
[11:56] <seb128> I tagged it tls-bb-incoming now
[12:04] <jbicha> seb128: yes, appstream needs to adapt to glib https://github.com/ximion/appstream/issues/222
[12:04] <gitbot> ximion issue 222 in appstream "0.12.6 test failures on Ubuntu" [Open]
[12:04] <seb128> jbicha, thx, maybe you can add that to the trello card?
[12:38] <Laney> YAKKKKKKKKKKKKK SHAVINNNNNNN
[12:39] <doko> did somebody already looked at poppler not migrating?
[12:40] <seb128> doko, not since glibc migrated today
[12:41] <cyphermox> seb128: https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/commit/?h=ubuntu&id=c3a5ea3adb4f9474c94f840a6beca83927c1b153
[12:41] <seb128> cyphermox, thanks!
[12:41] <seb128> on step closer from flicker free boot :)
[12:41] <cyphermox> I wonder
[12:41] <seb128> ?
[12:42] <cyphermox> (I mean, theoretically, sure, but in practice, there are lots more small things)
[12:43] <seb128> one step indeed
[12:43] <seb128> it's that many remaining
[12:43] <seb128> we are going to need the newer plymouth next cycle, which keeps the vendor logo on screen
[12:43] <seb128> and a intel video driver fix which is in newer upstream kernels
[12:43] <seb128> it's not that*
[12:44] <cyphermox> yup
[12:44] <cyphermox> I've heard of the vendor logo patches, those already exists (doesn't necessarily need to wait for upstream)
[12:45] <cyphermox> someone pointed out they'd like to see it ;)
[12:45] <seb128> well, everything is in upstream git master
[12:45] <cyphermox> that said, I mean, it's nice, but it also means we should then figure out a way to show our logo or progress elsewhere
[12:45] <seb128> I think it's late for disco now for that though
[12:45] <cyphermox> yeah, I agree
[12:45] <cyphermox> but next cycle, sure
[12:45] <seb128> they current implementation keeps the bios logo on screen
[12:46] <cyphermox> yes
[12:46] <seb128> and has a vendor/distro logo at the bottom
[12:46] <seb128> hopefully it's easy to put ours there and it looks nice :)
[12:46] <cyphermox> that's got to be theme dependent though
[12:48] <cyphermox> in other words, we'll all collectively need to discuss what to do about theming at early boot, even if that's just a matter of removing the aubergine background color
[12:49] <cyphermox> seb128: for plymouth next cycle I'd like to carefully review the patches we carry, and decide if we really, really still need all of them; and attempt to stick to upstream snapshots if plymouth maintainers still don't do releases
[12:50] <seb128> cyphermox, they do releases no? we had one this cycle
[12:50] <seb128> but yeah, agreed on the less patching
[12:50] <cyphermox> we had one this cycle but it's been few and far between IIRC
[12:51] <seb128> I go co-working every now and then with one of the upstreams so I would be happy to help talking about our delta/seeing what we can drop
[12:51] <cyphermox> cool
[12:51] <seb128> I can also nag them for releases if needed :)
[12:51] <cyphermox> I'm pretty sure some is just fluff
[16:30] <seb128> andyrock, just as a follow up, https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-control-center/commit/?id=13747461
[16:30] <seb128> andyrock, I included that in the .92 update, thx for the fix :)
[16:40] <ahasenack> hi, did we drop the cirrus xorg driver in disco?
[16:40] <ahasenack> I just had an experience where I created a vm with uvt-kvm (which uses libvirt), and X failed to come up
[16:40] <ahasenack> logs show it failed to find the cirrus driver
[16:41] <cpaelzer> ahasenack: I just remembered working with tjaalton on some other issue, there is the x-staging ppa which you might test as well if that is easy for you
[16:41] <cpaelzer> and @desktop-team cirrus is the default of libvirt since like forever and for the same reason won't change as long as possible (they are very strict on the XML-in-definition-out as a stable API of some sort)
[16:43] <ahasenack> "Failed to load module "cirrus" (module does not exist, 0)"
[16:43] <tjaalton> ahasenack: cirrus has a kernel driver now
[16:43] <tjaalton> so it should use modesetting
[16:43] <cpaelzer> ahasenack: e.g. in uvtool we only say "<video/>" and get cirrus by default
[16:43] <cpaelzer> tjaalton: could it be that this driver isn't in the -virt kernel builds?
[16:43] <ahasenack> tjaalton: let me paste the full logs
[16:43] <tjaalton> dunno
[16:43] <cpaelzer> ahasenack: whicih kernel flavor do you have running?
[16:44] <ahasenack> http://paste.ubuntu.com/p/d6ypgxzkyv/
[16:44] <ahasenack> cpaelzer: 4.19.0-13-generic
[16:44] <ahasenack> and I do have the meta linux-image-virtual
[16:45] <ahasenack> maybe it's in modules-extra
[16:45] <tjaalton> it is
[16:45] <ahasenack> ok, let me try that then
[16:45] <ahasenack> switch the hw back to cirrus in the vm, and install that extra modules package
[16:46] <ahasenack> cpaelzer: hm, how do I switch it back to cirrus? :)
[16:46] <cpaelzer> ahasenack: in virsh edit or in virt-manager?
[16:46] <ahasenack> the dropdown which had cirrus before, and where I selected qxl, no longer has cirrus
[16:46] <ahasenack> virt-manager
[16:46] <ahasenack> but, well, I can use virsh edit too I guess
[16:46] <cpaelzer> easy, just enter cirrus there ignoring the dropdown options
[16:46] <tjaalton> isn't qxl the default?
[16:46] <ahasenack> ah, and Cirrus != cirrus
[16:46] <ahasenack> ok, cirrus worked
[16:47] <ahasenack> tjaalton: wasn't here
[16:47] <cpaelzer> extras has /lib/modules/4.19.0-13-generic/kernel/drivers/gpu/drm/cirrus/cirrus.ko
[16:47] <ahasenack> ok,back to cirrus, saved, booting
[16:47] <cpaelzer> ahasenack: if that ends up working that would be a bug against the kernel to make it part of the normal modules and not -extra
[16:47] <tjaalton> seems to be default on my vm's
[16:47] <tjaalton> cpaelzer: that'd pull core drm too
[16:47] <ahasenack> ok, X didn't come up as expected, now installing extras
[16:48] <cpaelzer> tjaalton: well, if a default VM can't have UI that is a reason to move it to non-extra I think
[16:48] <cpaelzer> aren't there other graphic drivers needing drm already?
[16:49] <tjaalton> no
[16:49] <cpaelzer> tjaalton: /lib/modules/4.19.0-13-generic/kernel/drivers/gpu/drm/drm.ko is in linux-modules-4.19.0-13-generic already
[16:49] <ahasenack> I got a default of "qxl" when using virt-manager's wizard
[16:49] <tjaalton> they're all in extra
[16:49] <tjaalton> oh, ok
[16:49] <cpaelzer> ahasenack: yes qxl is amore modern default, but that is virt-manager trying to be smart (as I said before higher tools need to define that)
[16:50] <ahasenack> but uvt-kvm gave me cirrus. cpaelzer said earlier uvt-kvm doesn't specify anything, so it's the library's default that is taken, and that is cirrus?
[16:50] <tjaalton> alright
[16:50] <tjaalton> qxl.ko is in extra as well :)
[16:50] <cpaelzer> ahasenack: libvirt defaults to cirrus, uvtool doesn't specify anything -> cirrus, virt-manager defaults to qxl so that is what it is using
[16:50] <ahasenack> X started now, after I installed extras, and using cirrus
[16:51] <cpaelzer> ahasenack: tjaalton: qxl should be moved as well then
[16:51] <ahasenack> well, how did it work then, without extras, and with video qxl?
[16:51] <cpaelzer> or OTOH - the X11 stack should depend on the -extra package
[16:51] <cpaelzer> how about that - that would not make non-extra fat?
[16:51] <cpaelzer> and at the same time still fix the issue
[16:51] <tjaalton> uh no
[16:52] <cpaelzer> tjaalton: I believe you, but is there a quotable statement why "no"?
[16:52] <cpaelzer> just for -extra having so much stuf you rarely want?
[16:52] <cpaelzer> and you don't want to pull it in everywhere?
[16:53] <tjaalton> which extra should it depend on then?
[16:53] <tjaalton> X would force the generic kernel?
[16:53] <cpaelzer> I always get lost in the dependencies of the kernel
[16:53] <cpaelzer> I would have hoped one could somehow say "the -extra of the current one"
[16:53] <cpaelzer> but I read your answer as there is no such thing :-/
[16:53] <ahasenack> doesn't seem to be a linux-modules-extra metapackage
[16:53] <ahasenack> without a version
[16:54] <tjaalton> right
[16:54] <ahasenack> it's linux-image-generic or bust
[16:54] <cpaelzer> tjaalton: ahasenack: moving cirrus and maybe qxl to non-extra then as a soltion?
[16:54] <cpaelzer> or even "solution"
[16:54] <ahasenack> how did qxl work without the kernel module, it used a fallback solution?
[16:54] <cpaelzer> maybe it only needs the kernel module for e.g. KMS but works without by just X drivers?
[16:54] <cpaelzer> tjaalton: ^^ ?
[16:54] <ahasenack> cpaelzer: or have uvt-kvm change its default?
[16:55] <ahasenack> "empty" -> qxl?
[16:55] <tjaalton> ahasenack: the log should tell, maybe
[16:55] <cpaelzer> ahasenack: that would be fine for me as well
[16:55] <cpaelzer> ahasenack: but you need to tell multipass at least
[16:55] <ahasenack> let me just try qxl without the kernel module
[16:55] <cpaelzer> ahasenack: interested what comes out of that tes
[16:55] <ahasenack> booting
[16:56] <tjaalton> [    25.547] (EE) VESA(0): Specified fbbpp (24) is not a permitted value
[16:56] <ahasenack> X came up, let's see logs
[16:56] <tjaalton> that's why cirrus failed
[16:56] <cpaelzer> tjaalton: 24bit colors?
[16:56] <tjaalton> seems so
[16:57] <ahasenack> you mean, cirrus wasn't there, it tried vesa, which failed because of bpp?
[16:57] <tjaalton> yes, it should still work without kms and cirrus x driver
[16:58] <cpaelzer> oh so that is the actual issue that "changed" then
[16:58] <ahasenack> mh, in the working case, I don't have an X log file...?
[17:00] <tjaalton> .local/share/xorg/..
[17:01] <ahasenack> in ~?
[17:01] <tjaalton> yep
[17:01] <ahasenack> no such thing
[17:01] <ahasenack> ~root or ~ubuntu
[17:01] <ahasenack> maybe I have to login
[17:02] <cpaelzer> ahasenack: I tihnk you need to log in
[17:02] <tjaalton> gdm uses wayland
[17:02] <tjaalton> in the failing case it can't
[17:02] <tjaalton> without kms
[17:02] <ahasenack> ok, got it
[17:02] <ahasenack> it loaded qxl_drv.so from xorg
[17:02] <tjaalton> heh, right
[17:03] <ahasenack> http://paste.ubuntu.com/p/8jTHSxDtMX
[17:05] <ahasenack> so where do we stand? cirrus used to have an xorg module, now it's just kernel, and it's not installed by default?
[17:05] <ahasenack> (in vms)
[17:05] <tjaalton> afk for a bit
[17:05] <cpaelzer> ahasenack: yes that is what it seems
[17:05] <cpaelzer> ahasenack: I'm still leaning to move cirrus.ko to non-extra
[17:06] <cpaelzer> unless we have something much better based on the issues around 24 bpp
[17:06] <cpaelzer> ahasenack: and a bug to uvtool (please assign me) to make the default qxl
[17:06] <ahasenack> I can do the latter
[17:07] <sarnold> mdeslaur: ^^ does uvt need to be adapted for this too?
[17:07] <cpaelzer> ahasenack: and for moving the kernel module a bug against linux I gues?
[17:07] <ahasenack> well, if we change uvtool, then we don't need the module moved
[17:07] <ahasenack> the question is if something else doesn't specify a default
[17:08] <cpaelzer> ahasenack: the world is bigger than uvtool
[17:09] <cpaelzer> otoh: virt-manager has a different defaulöt
[17:09] <cpaelzer> virt-install as well
[17:09] <cpaelzer> hmm
[17:10] <cpaelzer> ahasenack: maybe open a bug to move it still
[17:10] <cpaelzer> just saying it would be their choice?
[17:10] <cpaelzer> I like if things work by default :-)
[17:11] <cpaelzer> and I'm somewhat afraid that other paths to spawn guests will still hit it
[17:11] <ahasenack> I always get a bot yelling at me when I file a kernel bug :)
[17:11] <ahasenack> but yeah
[17:11] <ahasenack> at least to have the discussion
[17:11] <cpaelzer> it is just 42k
[17:11] <cpaelzer> so not the biggest part in -modules
[17:11] <ahasenack> the deps might be
[17:12] <ahasenack> what's the name of the module again?
[17:12] <ahasenack> cirrus.ko?
[17:12] <ahasenack> (kernel module)
[17:12] <cpaelzer> ahasenack: /lib/modules/4.19.0-13-generic/kernel/drivers/gpu/drm/cirrus/cirrus.ko
[17:16] <ahasenack> ok, bugs filed
[17:16] <ahasenack> subscribed you to the kernel one, and assigned you to the uvtool one
[17:18] <tjaalton> well, vesa shouldn't try 24bit
[17:18] <tjaalton> but maybe just 16 by default
[17:18] <ahasenack> what are valid modes?
[17:18] <ahasenack> 8, 16, 32?
[17:18] <tjaalton> that'd fix the failure
[17:18] <tjaalton> kenrel fb doesn't support 24
[17:18] <ahasenack> what is qxl anyway, and why is it better than cirrus?
[17:19] <tjaalton> actually I thought qxl_drv.so was dead as well
[17:19] <ahasenack> oversight? :)
[17:19] <tjaalton> but apparently it has some features that are desirable
[17:22] <tjaalton> ahasenack: https://paste.fedoraproject.org/paste/O7QhcGDGN33k0x9PtKmGnQ/raw
[17:22] <tjaalton> should I build a driver for you?-)
[17:23] <ahasenack>  is that just picking 32 instead of 24 if 24 is requested?
[17:23] <ahasenack> if 32 is supported, that is
[17:23] <tjaalton> yes, which shouldn't be in this case meaning it'd fall back to 16
[17:23] <tjaalton> aiui
[17:24] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1818879 is the kernel bug, and I also mention this vesa issue and added a task for xorg
[17:24] <ubot5> Ubuntu bug 1818879 in xorg (Ubuntu) "pull cirrus.ko into main kernel package" [Undecided,New]
[17:24] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/uvtool/+bug/1818877 is the uvtool bug
[17:24] <ubot5> Ubuntu bug 1818877 in uvtool (Ubuntu) "uvtool should specify a default video device" [Undecided,New]
[17:24]  * ahasenack goes back into python2-removal land
[17:25] <tjaalton> ahasenack: I'll build a driver pkg in a minute
[17:25] <ahasenack> I never heard the words "build xorg" and "in a minute" together
[17:25] <tjaalton> vesa driver
[17:26] <ahasenack> :)
[17:26] <ahasenack> tjaalton: besides ldap and sssd, you also do display drivers? :)
[17:26] <sarnold> "don't worry, that xorg build will fail in a minute"
[17:26] <ahasenack> sarnold: that is more common
[17:27] <tjaalton> ahasenack: that's my actual job, or part of it
[17:27] <tjaalton> besides oem kernel
[17:27] <tjaalton> didn't even take a minute, just 36 seconds on sbuild
[17:27] <ahasenack> quite the contrast
[17:28] <tjaalton> https://aaltoset.kapsi.fi/tmp/xserver-xorg-video-vesa_2.4.0-1+ppa1_amd64.deb
[17:30] <tjaalton> freeipa et al is just a hobby, and on the back burner until fedora moves to java11..
[17:31] <ahasenack> tjaalton: worked, I haz display
[17:31] <ahasenack> hm, wait
[17:32] <ahasenack> better clear these logs and try again
[17:32] <ahasenack> I can't be sure which log is fresh and which one isn't
[17:32] <ahasenack> the one I thought was fresh is talking about qxl
[17:33] <tjaalton> the log should be in /var/log/
[17:33] <tjaalton> check the timestamp :)
[17:33] <ahasenack> ok, cirrus in the vm, no extra-modules package installed
[17:34] <ahasenack> no X log in /var/log
[17:34] <ahasenack> checking .local
[17:34] <ahasenack> it's a .1.log, not .0.log
[17:35] <ahasenack> ok, cirrus not loaded
[17:35] <ahasenack> unloads modesetting
[17:35] <ahasenack> ok
[17:36] <ahasenack> tjaalton: http://paste.ubuntu.com/p/gfmbsYc7g5
[17:36] <tjaalton> cirrus.ko available?
[17:36] <ahasenack> oh shoot
[17:36] <ahasenack> how
[17:37] <ahasenack> it's not in /lib/modules
[17:37] <ahasenack> must be in the initramfs
[17:37] <tjaalton> yeah, purge modules-extra
[17:37] <ahasenack> I did
[17:37] <tjaalton> hmm would think it ran update-initramfs
[17:39] <ahasenack> ok, now it's gone
[17:39] <ahasenack> x took a while to come up
[17:39] <ahasenack> it was probably trying all fallbacks
[17:39] <ahasenack> let's see
[17:40] <ahasenack> no cirrus in lsmod
[17:40] <tjaalton> and gdm does different things
[17:40] <ahasenack> and Xorg.logs in /var/log
[17:40] <ahasenack> this log keeps dancing around places
[17:40] <ahasenack> I have 3 xorg logs in /var/log now, with the same timestamp
[17:41] <tjaalton> hmm
[17:41] <tjaalton> still fails?
[17:41] <ahasenack> no, it worked
[17:41] <ahasenack> but I couldn't figure out quickly enough which log to check
[17:41] <ahasenack> so I rm -rf them, rebooted again
[17:41] <tjaalton> ok, check the other logs
[17:41] <tjaalton> if there's some weird failure
[17:41] <ahasenack> ok, I have /var/log/Xorg.0.log before login
[17:43] <ahasenack>  /var/log/Xorg.0.log before login, I'm at the user selection greeter: http://paste.ubuntu.com/p/PCDYQfv68H
[17:43] <ahasenack> tjaalton: ^
[17:43] <oSoMoN> I'm calling it a day, have a good evening everyone
[17:43] <ahasenack> better? 16bpp?
[17:43] <tjaalton> ahasenack: yeah, did the right thing
[17:43] <ahasenack> ah, and I see the 16bpp-iness when logging in
[17:44] <tjaalton> yep
[18:00] <mdeslaur> sarnold: good question
[18:24] <kenvandine> mvo: i'm running core beta but help URLs still aren't valid.  Shouldn't that be in beta by now?
[18:26]  * kenvandine tries edge
[18:27] <kenvandine> not in edge either
[18:27] <kenvandine> user-open error: Supplied URL scheme "help" is not allowed
[18:43] <mvo> kenvandine: yes, that looks fishy, its a bit late here already but we should talk about this tomorrow, this should work
[18:43] <kenvandine> mvo: ok, thanks
[18:43]  * kenvandine tested this... it worked before
[18:44] <mvo> kenvandine: hm, hm, I wonder what is going on if that used to work. we also have a (spread) test :/
[18:45] <kenvandine> yeah
[18:45] <kenvandine> it's failed in the check if it's in the allowed schemes
[18:45] <kenvandine> not even failing to set env or anything
[18:45] <kenvandine> it's that hard coded list
[18:45] <kenvandine> at least that's what it looks like
[18:52] <willcooke> night all