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