[05:34] <tjaalton> duflu: care to try --enable-xwayland-eglstream?
[05:34] <tjaalton> it's not enabled
[05:54] <duflu> tjaalton, Yeah I don't think I need to. I just thought you had already done so
[05:54] <duflu> Although I am almost set up to test it easily today
[05:54] <duflu> So maybe I will
[05:59] <tjaalton> cool
[06:00] <duflu> I remember documenting Xwayland rebuilds as a TODO in passing in another bug
[06:00] <duflu> But probably failed to log a bug for that specifically till now
[06:17] <didrocks> good morning
[06:25] <duflu> Morning didrocks
[06:25]  * didrocks reboots to answer duflu's new questions. Please think of asking everything at first
[06:25] <didrocks> the ping pong of new -> incomplete is a little bit counter-productive
[06:25] <didrocks> especially when new questions don't have links with previous
[06:26]  * didrocks reboots with drm=1
[06:31] <duflu> didrocks, I appreciate your frustration. I was working on Sunday to get on top of these new bugs
[06:38] <didrocks> duflu: don't work on Sunday. But I don't understand as well the passive-agressivness when it's your coworker to set to incomplete without pinging them.
[06:39] <didrocks> happened already on Friday, without pings, when both online, requesting for more info, which is fine but a ping would have been appreciated
[06:39] <duflu> didrocks, I wouldn't want to ping you on a Sunday. Even if I am working on a Sunday I keep chat closed
[06:39] <didrocks> and same with asking glxgears info. it sounds like the hope is to the reporter to never come back
[06:39] <didrocks> the ping was for Friday
[06:41] <duflu> didrocks, that's incorrect. I asked you the question 21 hours ago on Sunday. For good reason, because I just thought of it and wondered if your bug might be related to something else I had discovered. I'm sorry to annoy you. Just trying to figure bugs out.
[06:41] <didrocks> btw, I guess the importance can be reduced now in the bug as it's confirmed to be only drm = 1 and Xorg
[06:41] <didrocks> still sad to have a regression for something that worked for a year though
[06:41] <duflu> Yeah I agree
[06:41] <didrocks> duflu: no, on Friday, you set the bug as incomplete asking those: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1823301/comments/3
[06:41] <ubot5`> Ubuntu bug 1823301 in mutter (Ubuntu) "[nvidia] Shell hangs up at random times when using nvidia-drm.modeset=1" [High,New]
[06:41] <didrocks> while we were both connected
[06:42] <didrocks> then I answered them, had to set back to New, and on Sunday, yeah, the little game restarted
[06:43] <didrocks> that I can understand when we are both not connected, but when people are connected, feels really passive agressive to me
[06:43] <duflu> I don't use chat for bugs. I like to keep a permanent record of the information so that (a) no one has to remember; and (b) so that anyone else can pick it up later
[06:44] <duflu> didrocks, I don't mean to appear that way. I am just eager to answer bugs quickly, and with a permanent record
[06:44] <didrocks> I don't think this is the most effective way to progress on bugs that coworkers have IMHO
[06:44] <didrocks> but meh, let's disagree
[06:45] <duflu> Also, on Friday I had no time left. There would be no sense me asking a question in chat and then pasting it into the bug
[06:45] <didrocks> (and again, I mean when both are online at the same time)
[06:45] <didrocks> yeah, so maybe that could have been reported to Monday?
[06:45] <duflu> That's not true. I was out of time
[06:53] <duflu> tjaalton, first attempt of that option failed
[06:53] <duflu> Maybe a typo or in the wrong place?
[06:58] <duflu> Hmm, it still builds even with invalid flags
[07:01] <duflu> tjaalton, it appears I built it correctly and still no acceleration.
[07:01] <duflu> Do you know how to verify the binary?
[07:02] <duflu> Though it might be another Nvidia driver bug. I will soon downgrade again and see if things work better
[07:04] <duflu> Oh. tjaalton, "Xwayland -eglstream" is a thing. Maybe mutter needs to launch it differently?
[07:05] <tjaalton> duflu: ok, i've no idea :)
[07:05] <duflu> tjaalton, I launched another Xwayland using that option and still get llvmpipe in clients
[07:05] <duflu> So yeah long term we will need that rebuild, but there's some other issue
[07:10] <duflu> tjaalton, I wonder if we accidentally built mutter with EGLDevice support but no EGLStreams support?
[07:10] <duflu> They are different options
[07:34] <tjaalton> I'll check what fedora did
[07:35] <duflu> I guess I can also rebuild mutter easily and check that
[07:39] <oSoMoN> good morning desktoppers
[07:40] <didrocks> salut oSoMoN
[07:41] <duflu> Morning oSoMoN
[07:42] <oSoMoN> salut didrocks
[07:42] <oSoMoN> good afternoon duflu
[07:54] <RAOF> tjaalton: Is GL *meant* to work in XWayland-EGLStream? My understanding was that it enabled *2D* (ie: XRender) acceleration, not GLX.
[07:54] <RAOF> (Also duflu, I guess :))
[07:56] <duflu> RAOF: I was wondering that too
[07:59] <duflu> Hmm, and now I am testing 390 for another bug thats probably a new reason why EGLStreams isn't working
[08:02] <tjaalton> RAOF: again no idea, this is new territory for me
[08:02] <tjaalton> but what about this https://src.fedoraproject.org/rpms/egl-wayland/blob/master/f/10_nvidia_wayland.json
[08:02] <tjaalton> oh, we have that
[08:03] <Laney> moin
[08:04] <RAOF> tjaalton: I'm *pretty* sure XWayland won't do GLX even with the EGLStreams patches.
[08:05] <willcooke> morning
[08:05] <duflu> Morning Laney and willcooke
[08:05] <RAOF> (and that's for EGL external platform, which isn't GLX 😀)
[08:05] <tjaalton> RAOF: ah, right.. probably so
[08:06] <duflu> So definitely a bug, and not fixable right now. Definitely avoid Wayland on Nvidia :/
[08:06] <willcooke> hi duflu
[08:07] <RAOF> I don't even think there's a *plan* to make GLX on XWayland-EGLStream work
[08:07] <duflu> That's unfortunate for the Wayland+Nvidia fans
[08:08] <duflu> RAOF: Though es2_info also reports LLVMpipe. Same thing?
[08:08] <RAOF> As XWayland doesn't have the loadable DDX system that non-mesa platforms use in Xorg.
[08:09] <RAOF> duflu: es2_info queries the X11 EGL backend, which goes through GLX
[08:09] <didrocks> hey Laney, willcooke
[08:09] <oSoMoN> good morning willcooke, Laney
[08:09] <duflu> Yeah I thought so
[08:09] <willcooke> hi didrocks oSoMoN!
[08:09] <willcooke> Foggy here today, and not very warm #weatherchat
[08:09] <RAOF> (if you built es2_info on the Wayland platform, it should provide NVIDIA details)
[08:09] <duflu> Seems X11 will dominate for even longer than I thought
[08:10] <tjaalton> here's for another 35 years ;)
[08:10] <willcooke> :DD
[08:11] <willcooke> X11 becomes the new Fortran
[08:11] <Laney> hi duflu tjaalton willcooke RAOF didrocks oSoMoN
[08:11] <willcooke> morning Laney, how goes?
[08:11] <duflu> willcooke, if you've seen the Xorg source code it kind of is already
[08:11] <willcooke> :D
[08:12] <duflu> But all this hinges on Nvidia still being important for 35 years
[08:12] <tjaalton> duflu: according to this blog post nvidia driver support for xwayland won't arrive before fall https://blogs.gnome.org/uraeus/2019/04/03/preparing-for-fedora-workstation-30/
[08:12] <duflu> tjaalton, it's fall right now ;)
[08:12] <tjaalton> haha
[08:12] <duflu> Some would say autumn
[08:24] <seb128> good morning desktopers
[08:24] <oSoMoN> salut seb128
[08:24] <seb128> lut oSoMoN, en forme ?
[08:25] <oSoMoN> oui, et toi?
[08:25] <seb128> en forme ! passé le w.e en France seul, bien reposant :)
[08:26] <willcooke> morning seb128
[08:26] <seb128> hey willcooke! how are you? had a good w.e?
[08:27] <willcooke> seb128, worst golf competition ever.  I really sucked.  And got caught up with work yesterday.  So I've got that going for me...
[08:27] <willcooke> oh, and I feel like I'm getting a cold.
[08:27] <willcooke> :DD
[08:27] <seb128> :(
[08:27] <seb128> doesn't sound like a winning w.e :/
[08:28] <willcooke> #2ndtolast
[08:28] <Laney> :D
[08:28] <duflu> Morning seb128
[08:28] <seb128> hey duflu
[08:29] <duflu> RAOF: I seem to have a real problem still... glmark2-wayland uses LLVMpipe also
[08:30] <RAOF> Ok, *that* is a real problem. That's my go-to test of NVIDIA under Mir.
[08:31] <duflu> Yeah
[08:33] <duflu> Hmm, fun fact: If your machine is slow enough then mutter can't match Shift with the key you are shifting. Seems it detects those two things a little too disparately
[08:42] <RAOF> Putting everything ona single eventloop has some downsides. Who knew!
[08:44] <duflu> RAOF: Yeah it's pretty terrible. I have performance bugs in progress for years now because of the single threadedness
[08:44] <duflu> And trying to work with it
[08:45] <duflu> tjaalton, RAOF, my problem with glmark2-wayland was that uninstalling Nvidia drivers seems to have autoremoved libnvidia-egl-wayland1. Then you install a new Nvidia driver and everything works except Wayland clients on Nvidia
[08:46] <duflu> I feel like that should be autoinstalled or at least never uninstalled if it's that important
[08:47] <tjaalton> nvidia doesn't depend on it
[08:47] <tjaalton> but there are file conflicts with the old version
[08:47] <tjaalton> so it got removed because of that
[08:48] <RAOF> Something should depend on it, right? It's the external EGL platform.
[08:50] <tjaalton> something like.. the driver? :)
[09:00] <duflu> RAOF: Your ~/Desktop isn't a symlink to ~ or anything crazy right?
[09:02] <RAOF> Nope!
[09:02] <RAOF> It's a real (empty) folder!
[09:03] <duflu> RAOF: Hmm, 0755 ?
[09:03] <duflu> Or 0700 at least
[09:04] <duflu> Maybe bcachefs is confusing the file monitor?
[09:06] <RAOF> <duflu "Maybe bcachefs is confusing the "> That seems a stretch.
[09:07] <duflu> RAOF, yeah well the truth is going to be strange. I can't see any option you can accidentally set for those folders to appear
[09:07] <RAOF> Maybe xdg.dirs is set up strangely, though.
<font color="#0087FF">d</font><font color="#B58900"><b>r</b></font><font color="#DC322F"><b>w</b></font><font color="#859900"><b>x</b></font><font color="#B58900">r</font><font color="#808080">-</font><font color="#859900">x</font><font color="#B58900">r</font><font color="#808080">-</font><font color="#859900">x</font>     <font color="#808080">-</font> <font color="#B58900"><b>chris</b></font> <font
[09:07] <RAOF> color="#268BD2">10 Dec  2018</font>  <font color="#0087FF">Desktop</font></pre>
[09:07] <RAOF> drwxr-xr-x     - chris 10 Dec  2018  Desktop
[09:07] <RAOF> Yu.!
[09:07] <RAOF> Yup!
[09:08] <RAOF> ```
[09:08]  * RAOF sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/wUSTMYvLZtBdvfdXPJEKhtmN >
[09:08] <RAOF> Hello!
[09:09] <duflu> We apologise for this temporary break in transmission
[09:09] <duflu> RAOF: How about ~/.config/user-dirs.dirs ?
[09:09] <RAOF> That's what I just dumped.-
[09:09] <RAOF> Everything points to "$HOME/"
[09:10] <RAOF> Oh, yeah, IRC.
[09:10] <RAOF> Sorry.
[09:10] <duflu> OK, thanks.
[09:17] <RAOF> That's why it shows $HOME as the desktop, but not why it hangs the compositor for a couple of seconds and leaks 50MB each time the desktop changes 😀
[09:21] <duflu> RAOF: I am guessing there's a linear search somewhere, or something else related to 10GB of memory
[09:22] <RAOF> It's not doing something silly like recursively searching the path for desktop files or something?
[09:23] <duflu> RAOF: It will probably trigger garbage collection, which is slow and starts every 10 seconds (because you are invoking JS code more frequently than that)
[09:23] <duflu> Extra slow across 10GB
[09:24] <duflu> So essentially a memory leak. But not one any other user is likely to hit in a hurry
[09:24] <duflu> It's on my list of performance things to fix still
[09:25] <duflu> I hope you are OK with changing those dirs so they don't appear
[09:26] <RAOF> Oh, I've already changed that file.
[09:26] <RAOF> And it hangs the compositor from the get go, even when the memory usage is only 300MB
[09:27] <duflu> Weird. Some other customisation or upgrade bug no doubt
[09:29] <RAOF> Editing files on the desktop seems like a not-infrequent use case.
[09:29] <RAOF> Which would also trigger this, as autosave kicks in.
[09:29] <RAOF> (but not as quickly)
[09:30] <RAOF> Anyway, I'll switch to the plain GNOME session and tell you how long it takes to leak 10G of memory 😀
[09:30] <duflu> Yeah there are leaks but those will likely be different leaks
[09:31] <duflu> I guess it's up to me to come up with a user-friendly procedure for enabling heap profiling
[09:31] <duflu> and retrieving results
[09:39] <RAOF> That'd be nice!
[09:39] <RAOF> You could also just point me at some documentation.
[09:39] <RAOF> It doesn't have to be *terribly* user-friendly 😀
[09:43] <duflu> RAOF: Heh in that case: https://gperftools.github.io/gperftools/heapprofile.html
[09:44] <duflu> Also, isn't it night time?
[09:45] <duflu> You could set it up system wide but disabled till you send a signal
[09:45] <duflu> I've never tested the stability of that though
[09:46] <duflu> Oops. That's the CPU profiler only that's off till you turn it on
[11:22] <seb128> ricotz, hey, did you look at libdmapsharing failing to build with the new vala?
[11:30] <ricotz> seb128, oh, I thought I fixed this upstream
[11:30] <seb128> ricotz, I looked at the commits in git but maybe the title/description wasn't obvious to me
[11:34] <andyrock> rbalint: hey hey can you create an ubuntu/bionic branch for software-properties ?
[11:37] <ricotz> seb128, hmm, I think this was something weird about the source management there since the generated source are in git
[11:42] <seb128> ricotz, k, I'm not sure to understand what it means for the patch though, do you have one we can use?
[11:43] <ricotz> seb128, https://paste.debian.net/plain/1076653
[11:44] <ricotz> I assume the package carries further patches to resolve a linker issue?
[11:44] <seb128> ricotz, thx
[11:45] <seb128> ricotz, no, no patch atm, build might still fail then, let me try
[11:46] <ricotz> ah, I built the master branch
[11:50] <ricotz> seb128, https://paste.debian.net/plain/1076654
[11:51] <seb128> ricotz, thx!
[11:52] <ricotz> LIBDMAPSHARING_3_0 branch has more issues :\
[11:52] <ricotz> not surprising with the last commit being from 2017
[11:59] <rbalint> andyrock, looking
[12:07] <rbalint> andyrock, done
[12:34] <andyrock> rbalint: out of curiosity which command did you use to generate it?
[12:34] <andyrock> and thanks!
[12:53] <jibel> tsimonq2, Hey, if you want to play with a multi-layer image, there is today's build at http://people.canonical.com/~platform/ubuntu-canary/20190408/
[12:54] <jibel> it's completely untested
[13:02] <seb128> ricotz, do you plan to mp the fix on gitlab?
[13:03] <ricotz> seb128, did it work out? -- no, not in its current state, there are more issues with the vapi build in 3_0 and the unlinking in master
[13:04] <ricotz> *underlinking
[13:04] <seb128> ricotz, yes, it fixed the build applied on the current package
[13:04] <seb128> well, I'm going to open at least an issue then so I've a reference for the patch header
[13:04] <seb128> thx
[13:05] <ricotz> ok, thanks
[13:12] <tsimonq2> jibel: Awesome, thank you!
[13:12] <seb128> ricotz, https://gitlab.gnome.org/GNOME/libdmapsharing/issues/7
[13:12] <tsimonq2> Does this mean ubuntu-cdimage has to put the images elsewhere? How'd you get those there?
[13:12] <gitbot> GNOME issue 7 in libdmapsharing "2.9.39 fails to build with vala >= 0.43" [Opened]
[13:16] <didrocks> tsimonq2: we proposed some patches for it to be reviewed by sil2100. Unsure if this is enough though
[13:16] <didrocks> tsimonq2: /!\ the script has some small failures, we are testing/fixing
[13:17] <tsimonq2> ack
[13:18] <tsimonq2> didrocks: Just to ubuntu-cdimage?
[13:19] <didrocks> tsimonq2: yep https://code.launchpad.net/~jibel/ubuntu-cdimage/support_ubuntu_subproject/+merge/365598
[13:20] <didrocks> but maybe some other bits are needed
[13:20] <sil2100> eeek
[13:20]  * sil2100 forgot about the MP last week
[13:20] <sil2100> Looking at it in a bit
[13:20] <didrocks> no worry sil2100, this is why we asked you to copy the current image :)
[13:21] <didrocks> sil2100: thanks! Maybe that's not enough, but we are quite sure this is needed
[13:36] <seb128> andyrock, hey, did you see my ping about https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/423 on friday?
[13:36] <gitbot> GNOME issue (Merge request) 423 in gnome-control-center "online-accounts: Don't segfault if get_all_providers_cb is called during init" [1. Crash, 6. Component: Online Accounts, Opened]
[13:37] <andyrock> nope :)
[13:37] <andyrock> but to fix it properly upstream the best way is to change goa API
[13:37] <andyrock> to make it sync or cancellable
[13:38] <andyrock> I'll take another look later this week
[13:40] <seb128> andyrock, k
[13:55] <andyrock> rbalint: https://code.launchpad.net/~azzar1/software-properties/+git/software-properties/+merge/365668 can you take a look? thx!
[14:29] <rbalint> andyrock, i used pull-lp-source -d and gbp import-dscs , with some shell history, but don't have a single script yet
[15:19] <brlin> Can anyone review this? : https://code.launchpad.net/~buo-ren-lin/gnome-system-monitor/fix-snap/+merge/364768
[15:45] <Trevinho> morning folks
[15:47] <willcooke> hi Trevinho
[15:48] <popey> https://usercontent.irccloud-cdn.com/file/Na1tpRPD/Current%2019.04%20on%20nVidia
[15:48] <popey> ^^ Just updated my 19.04 rig and now I have *massive* fonts in the indicator and shell activities thing. Is this known?
[15:58] <willcooke> popey, I think didrocks and/or duflu saw that before, but they're both EOD now.
[15:58] <popey> kk
[15:58] <willcooke> If you can ask again tomorrow morning, please do.  I will try and remember
[15:59] <popey> will do
[16:16] <popey> willcooke: just switched to 200% scale and back again and it made the big stuff go away
[16:18] <Eickmeyer> clobrano: I created a patch based on the upstream commit in materia-gtk-theme made by the author. I can confirm that it works. Thanks for all the help!
[16:19] <clobrano> Eickmeyer: great!
[16:22] <willcooke> popey, ah, kk. That sounds familiar
[16:37] <Laney> that's what didier has been reporting
[16:46] <cyphermox> Laney: are you preparing a new ubiquity upload?
[16:48] <Laney> nope, but I could do
[16:48] <Laney> I think I asked on one of the MPs :>
[16:48] <cyphermox> oh, I didn't see
[16:48] <cyphermox> it's fine, I was about to go merge rik's changes
[16:48] <Laney> go for it
[16:48] <cyphermox> I can do the upload if you want me to
[16:48] <cyphermox> ok
[16:48] <Laney> ubiquity uploads are annoying for me
[16:49] <Laney> gbp buildpackage / debuild don't make a proper package (they lose the d-i stuff)
[16:49] <Laney> so I have to use one of those and then unpack the package it makes, run debian/rules update again and rebuild the source package
[16:49] <Laney> dunno why
[16:50] <cyphermox> oh
[16:50] <cyphermox> I just make -C d-i/  and gbp buildpackage --git-ignore-new or whatnot
[16:51] <cyphermox> after making sure things are properly committed, of course, but we don't want to include and commit d-i bits
[16:51] <cyphermox> (in the upload yes, in the tree no)
[16:53] <Laney> right
[18:44] <Trevinho> popey: yeah, it's already fixed in a MP waiting for sponsor
[18:56] <Trevinho> popey: you can also try pkgs at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3695
[19:24] <ricotz> seb128, could you pick up vala 0.44.3 bugfix release from debian git?
[19:25] <seb128> ricotz, is anyone going to upload it (in which case we can sync)?
[19:25] <ricotz> seb128, not sure I waited a week and 0.44.2 wasn't uploaded
[19:26] <ricotz> j_bicha seems afk for now
[19:26] <seb128> ricotz, k, I have a look but probably tomorrow it's getting late tonight and I don't plan to stay at the computer long
[19:26] <ricotz> seb128, ok, please don't forget it
[19:26] <seb128> yeah, he said he needed to step back from Debian/Ubuntu work and that he would blog about it
[19:26] <seb128> k
[19:27] <ricotz> thanks
[19:29] <seb128> ricotz, you don't have any idea about bug #1823426 by any chance? ;)
[19:29] <ubot5`> bug 1823426 in librsvg (Ubuntu) "librsvg ftbfs in disco (i386 only)" [High,New] https://launchpad.net/bugs/1823426
[19:29] <seb128>      = note: `N1024` must be defined only once in the type namespace of this module
[19:29] <seb128> For more information about this error, try `rustc --explain E0428`.
[19:29] <seb128> error: Could not compile `typenum`.
[19:30] <seb128> I wonder if that's a rust toolchain issue or a librsvg one
[19:30] <seb128> (I didn't find a report/commit upstream in librsvg that seems to correspond)
[19:31] <ricotz> seb128, librsvg git built on disco earlier today
[19:32] <seb128> the issue is i386 only
[19:32] <seb128> I guess you tried on amd64?
[19:32] <ricotz> ah correct
[21:24] <tjaalton> RAOF: intel-opencl-clang and -graphics-compiler are now on the disco NEW queue, if you have time to have a look. -opencl-clang has an older upload there that should be dropped