[07:21] <didrocks> good morning
[07:31] <duflu> Hi didrocks
[07:32] <didrocks> hey duflu
[07:37] <duflu> didrocks, did you notice disco doesn't use a gradient on the login screen any more? :)
[07:43] <didrocks> duflu: I didn't, but TBH, I don't really pay attention, it's mostly autotyping by then :)
[07:43] <didrocks> I saw your bug report, I think it's easy for anyone interested to update the patch (just annoying G-S hardcodes thoses and don't use the theme)
[08:21] <tjaalton> duflu: hi, have you tried intel-media-va-driver? only the non-free version seems to work here
[08:21] <tjaalton> this is the new driver for broadwell and up
[08:23] <duflu> tjaalton, no I haven't. I felt we have enough backward compatibility problems so recommending a new driver that works on even fewer Intel chips would only make life more difficult. But if it does work then we can recommend it. Just don't install by default unless the system requirements are met
[08:24] <tjaalton> right
[08:25] <duflu> tjaalton, I think I was assuming that libva won't try multiple drivers in order if all installed. Maybe I should test that on <=haswell
[08:25] <duflu> Actually I don't know if there is an order or priority even
[08:26] <tjaalton> there kinda was, it's gone from the unreleased version
[08:26] <tjaalton> right now it'd use the old driver
[08:26] <tjaalton> if both are installed
[08:27] <duflu> Oh! Simple answer: /usr/share/doc/intel-media-va-driver/README.Debian
[08:27] <tjaalton> yeah
[08:28] <duflu> There must be some autodetection or else we couldn't have all those drivers (*_drv_video.so) installed simultaneously.
[08:28] <duflu> So either the readme is out of date, or it will already try i965 first
[08:29] <tjaalton> it will, just said so ;)
[08:29] <duflu> Maybe we can ship the new one too
[08:29] <tjaalton> maybe the next libva will do something else
[08:30] <duflu> tjaalton, I am assuming that the new driver will simply refuse to load like nouveau or radeon on Intel hardware if using Haswell
[08:30] <tjaalton> if forced? probably
[08:31] <duflu> So we then could say to always try i^D before i965
[08:31] <duflu> So we then could say to always try iHD before i965
[08:32] <tjaalton> right
[08:32] <duflu> You'd just need each driver to export priority information and test them all before making a final choice
[08:32] <tjaalton> https://github.com/intel/libva/commit/b7203fe3b1fa633cece9cd9e5715b6477a708455
[08:33] <tjaalton> upstream dropped the driver list, so I'm not sure what it'll do now
[08:34] <duflu> tjaalton, I'll try and remember to set up an old Intel system some time and see
[08:36] <tjaalton> I have one
[08:36] <tjaalton> not sure which version it has
[08:36] <tjaalton> of the distro
[08:36] <duflu> tjaalton, hmm it is failing on Kaby Lake, which is surprising (env LIBVA_DRIVER_NAME=iHD vainfo)
[08:37] <tjaalton> duflu: which version?
[08:37] <tjaalton> free or non-free
[08:37] <tjaalton> probably free
[08:38] <duflu> tjaalton, the one in archive yeah
[08:38] <tjaalton> non-free is still on the queue
[08:47] <duflu> tjaalton, it's all bad news. iHD on Xorg fails to init and fails to fall back so mpv keeps it loaded but uses SW. On Wayland, the old i965 driver seems to have stopped working in disco, so that's a new bug
[08:47] <seb128> good morning desktopers
[08:47] <duflu> Morning seb128
[08:48] <seb128> hey duflu, how are you?
[08:48] <tjaalton> duflu: ha, ok
[08:48] <duflu> seb128, just more frustrated now. More unresolved bugs. How are you?
[08:48] <seb128> hey tjaalton
[08:48] <tjaalton> howdy
[08:48] <seb128> duflu, oh :( which one today?
[08:48] <duflu> Not logged yet :)
[08:49] <duflu> Unless you count bug 1813119
[08:49] <ubot5> bug 1813119 in gnome-shell (Ubuntu) "In Ubuntu 19.04, the wrong background (a gradient) flashes up briefly during the login animation" [Undecided,New] https://launchpad.net/bugs/1813119
[08:49]  * duflu logs a new one for i965_drv
[09:01] <willcooke> morning all
[09:02] <duflu> Morning willcooke
[09:03]  * Laney nods
[09:04] <duflu> Morning Laney
[09:04] <didrocks> hey seb128j, willcooke, Laney
[09:05] <jibel> Hi all
[09:05] <didrocks> hey jibel!
[09:05] <jibel> :)
[09:05] <oSoMoN> good morning desktoppers
[09:06] <seb128> hey <list of those who just said good morning> :)
[09:06] <duflu> tjaalton, happy Thursday: bug 1813131
[09:06] <ubot5> bug 1813131 in intel-vaapi-driver (Ubuntu) "i965_drv_video.so doesn't load any more if a Wayland server is present [failed to resolve wl_drm_interface(): /lib/x86_64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_drm_interface]" [Undecided,New] https://launchpad.net/bugs/1813131
[09:07] <duflu> Hi jibel
[09:07] <duflu> and hi oSoMoN
[09:07] <tjaalton> hehe
[09:36] <tjaalton> duflu: sounds like it's more of a bug in mesa though? it migrated to meson..
[09:37] <tjaalton> so maybe the build is buggy
[09:38] <willcooke> changing sessions, brb
[09:39] <duflu> tjaalton, yes I agree. The intel-vaapi-driver source has used that symbol for years
[09:40] <duflu> And it's still used in trunk
[09:41] <duflu> Morning willcooke
[09:41] <willcooke> :)
[09:42] <duflu> Again. I am distracted and not trying to be facetious
[09:44] <willcooke> ha
=== cpaelzer__ is now known as cpaelzer
[11:24] <willcooke> Hm
[11:25] <willcooke> Perhaps I'm going mad, but I would swear that the old "hold down alt and drag anywhere on a window" changed to super with GNOME Shell.
[11:25] <willcooke> Mine is now back at alt again?!
[11:25] <willcooke> I did install the vanilla GNOME session this morning, if that makes any different
[11:25] <willcooke> difference
[11:25]  * willcooke tries it on Disco
[11:26] <willcooke> yeah, it's super on Disco
[11:26] <willcooke> and I thought everywhere else
[11:26] <willcooke> perhaps the vanilla gnome desktop packages changed something?
[11:26] <willcooke> Perhaps I did
[11:26] <willcooke> strange
[13:09] <xnox> seb128, Laney - has anybody started to look into udisks2 autopkgtest failure in disco-proposed, possibly with/without/due to new-kernel/new-systemd?
[13:09] <xnox> on ppc64el only
[13:09] <xnox> was hoping for a pair programme ;-)
[13:09] <seb128> xnox, I've it on my backlog but didn't look yet, if you want to do that it would be welcome :)
[13:10] <xnox> ha
[13:15] <xnox> could be new mdadm too at play =/
[13:18] <seb128> right, the last successful was with mdadm rc1
[13:19] <xnox> seb128, check this out
[13:19] <xnox> upstream-system      PASS
[13:19] <xnox> ubuntu@dradis:~/udisks2-2.8.1$ uname -a
[13:19] <xnox> Linux dradis 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:57:45 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux
[13:19]  * xnox upgrades kernel
[13:19] <xnox> but also this is baremetal, not in qemu.
[13:23] <seb128> we had an earlier identic failure with mdadm rc1 so might not be it
[13:27] <seb128> well diff between a fail and a working retry from decembre there are no package difference, same kernel version in the autopkgtest instance
[13:27] <seb128> seems it was flacky and now is just failing
[13:47] <xnox> seb128, right, with v4.19 kernel got another flake (different), then a pass. Upgrading to new systemd from proposed now.
[13:47] <xnox> to see if it stays flakey, or gets significantly worse.
[13:52] <kenvandine> oSoMoN: gnome-3-28-1804 in candidate includes gtk3-locales
[13:53] <kenvandine> oSoMoN: maybe you should do a test build of chromium using the gnome extension PR without your gtk3-locales part
[13:53] <kenvandine> oSoMoN: sorry... building chromium can't be fun :-D
[14:06] <xnox> seb128, ok it passes, eventually with all proposed too.
[14:06] <seb128> :(
[14:06] <xnox> seb128, i'll rerun the test one last time; then will request to add it to the "big packages" such that it gets a bigger VM
[14:06] <xnox> seb128, then i don't know.
[14:06] <seb128> k
[14:06] <xnox> i guess one has to dig into where the race is, and make tests probe and wait for things more.....
[14:12] <oSoMoN> kenvandine, ack, thanks! I'll test with libreoffice first, it builds an order of magnitude faster
[14:12] <kenvandine> awesome
[14:17] <xnox> seb128, it passed =) today is a good day
[14:17] <xnox> http://autopkgtest.ubuntu.com/packages/u/udisks2/disco/ppc64el
[14:17] <seb128> xnox, did you just retry or did you get a more powerful VM?
[14:17] <xnox> seb128, simple retry
[14:17] <xnox> it's not added to "big_packages" yet
[14:17] <seb128> hum, k
[14:17] <seb128> lucky then :)
[14:18] <xnox> seb128, and the cloud is quiet at the moment, and doesn't have like 10,0000 of things running
[14:18] <kenvandine> oSoMoN: let me know when it's ready so i can test it too
[14:18] <seb128> xnox, so probably a case of "things are too slow and the test doesn't wait enough" :/
[14:18] <xnox> in three harmonies.
[14:20] <mdeslaur> Is anyone chasing down the "auto-multiple-choice" package failing its autopkgtests because of a theming issue?
[14:24] <seb128> mdeslaur, I don't think so
[14:25] <seb128> mdeslaur, I can have a look, thanks for pointing it out
[14:25] <mdeslaur> thanks seb128
[14:43] <jbicha> seb128: I can look at auto-multiple-choice this weekend
[14:47] <seb128> jbicha, thx
[14:53] <oSoMoN> kenvandine, I unpacked the libreoffice snap built with the gnome extension, removed the gtk3 translations, repacked and installed, and it doesn't work, but I know why: we need to add "gnome-platform/usr/share/locale-langpack" to the list of paths in bindtextdomain.c
[14:54] <kenvandine> oh.. i thought we did that already :)
[14:54] <kenvandine> ok, that's an easy fix
[14:54] <kenvandine> oSoMoN: can you suggest that to diddledan so he can add it to his PR?
[14:55] <oSoMoN> kenvandine, yes, I'll actually test it first, to make sure it's enough
[14:55] <kenvandine> cool
[15:04] <jamesh> jbicha: hi.  I'll see if I can separate out the GTK inhibit portal changes for my work day tomorrow (it might just be the single commit, but I need to check if there's anything related)
[15:05] <jbicha> jamesh: I was going to take a look this weekend so maybe wait until Monday to see what I come up with
[15:06] <seb128> jbicha, Laney, the gnome-desktop/bubblewrap fix doesn't have the warnings in bionic so it's only a problem with the cosmic version (also no warning in disco)
[15:07] <jbicha> seb128: ok let's add that to my list too :)
[15:07] <seb128> jbicha, thx
[15:07] <jamesh> jbicha: https://gitlab.gnome.org/GNOME/gtk/commit/3fc319ff1be391430f23701673253e1c0994a0cc might be all that's needed
[15:09] <jbicha> jamesh: oh I'm sorry, I thought you were talking about xdg-desktop-portal, so please look into that tomorrow and let me know if you need that (or any other commits) SRU'd to bionic
[15:43] <kenvandine> jbicha: are you planning a bionic SRU for xdg-desktop-portal?
[15:46] <kenvandine> jbicha: i have it built in a PPA for testing
[15:48] <jbicha> kenvandine: I figured you were doing it since I saw your cosmic SRU in progress :)
[15:48] <kenvandine> jbicha: yeah.. i am planning to
[15:48] <kenvandine> jbicha: i didn't want you duplicating work
[15:49] <jbicha> kenvandine: what's interesting to me is how the libflatpak issue intersects with https://github.com/flatpak/xdg-desktop-portal-gtk/issues/166
[15:49] <gitbot> flatpak issue 166 in xdg-desktop-portal-gtk "possible unexpected attachments" [Closed]
[15:49] <jbicha> so I guess that will be for the next SRU
[15:52] <acheronuk> jbicha kenvandine: would be appreciated to coordinate a SRU of the KDE portal with that
[15:52] <acheronuk> See: https://lists.ubuntu.com/archives/kubuntu-devel/2018-December/011748.html
[15:53] <kenvandine> acheronuk: yeah
[15:55] <jbicha> acheronuk: what kind of coordination did you have in mind?
[15:56] <kenvandine> i was thinking just letting you guys know when i upload xdg-desktop-portal to bionic
[15:57] <jbicha> kenvandine: will xenial be getting xdg-desktop-portal 1.0.3 too?
[15:57] <kenvandine> jbicha: yes
[15:57] <acheronuk> ^^^ more or less that. I'm not aware of any issue that mean they MUST be updated together, but I'll check into that as I don't know for sure
[15:58] <kenvandine> acheronuk: i have mentioned this to sitter
[16:00] <jbicha> seb128: could you subscribe desktop bugs to xdg-dbus-proxy LP: #1811824
[16:00] <ubot5> Launchpad bug 1811824 in xdg-dbus-proxy (Ubuntu) "[MIR] xdg-dbus-proxy" [Undecided,New] https://launchpad.net/bugs/1811824
[16:00] <acheronuk> kenvandine: ok. he is not doing any active k/ubuntu dev work now, so in practical terms implementation is for me
[16:01] <acheronuk> or tsimonq2 if I am not around
[16:01] <kenvandine> acheronuk: ah, ok thanks
[16:02] <seb128> jbicha, k
[16:24] <czajkowski> c
[16:31] <seb128> jbicha, https://launchpadlibrarian.net/407988119/auto-multiple-choice_1.4.0-1_1.4.0-1+testubuntu1.diff.gz fixes the autopkgtest issue mentioned earlier, should I upload or do you want to try a better solution/to get something in Debian? (is that a gtk change to start warning about missing icons?)
[17:20] <jbicha> seb128: you can upload that if you like. The timing of the test failures started after https://launchpad.net/ubuntu/+source/yaru-theme/19.04 there wasn't a gtk3 upload at the right time to be the failure trigger
[17:23] <jbicha> Laney: did we want to do a 3.31 git snapshot of mutter? because the gsettings-desktop-schemas conflict with mutter 3.30 is annoying
[17:24] <jbicha> other alternatives: we could remove the 3.31 g-d-s for now from disco-proposed or I could add dummy gsettings keys and drop the Breaks for now
[17:27] <Laney> jbicha: Trevinho's worked on many build system issues
[17:27] <Laney> it's probably best to wait for the next release given that
[17:27] <Laney> the problem is they dropped keys? feel free to patch them back in imho
[17:27] <Trevinho> or we use a snapshot, but...
[17:27] <jbicha> renamed keys :(
[17:27] <jbicha> ok
[17:28] <Laney> you already told all in-archive consumers of those keys?
[17:28] <Trevinho> if you want a current git snapshot for mutter talk now, or I won't do it later xD
[17:28]  * Laney wouldn't bother, you go get the SRU finished :P
[17:28] <Trevinho> yep I do agree
[17:29] <Trevinho> the annoying stuff has been done anyway, so feel free to inherit my branch in case.
[17:31] <jbicha> sure, I'll add the keys back since that will give us more time to make sure everything is working without holding things up
[18:14] <willcooke> night all