[04:48] good morning [04:51] salut didrocks [04:52] salut jibel [05:12] Morning didrocks and jibel [05:40] good morning duflu [06:27] good morning desktoppers [06:36] Morning oSoMoN === pstolowski|afk is now known as pstolowski [08:01] morning all [08:03] yo de yo [08:03] hey marcustomlinson, Laney [08:03] morning folks [08:04] and a Trevinho [08:04] hi didrocks [08:06] hi Dan Rock and Mark Trevor [08:07] duflu: hey still here? [08:07] Morning marcustomlinson, Laney and Trevinho... [08:07] yes? [08:08] hello Dieter der Vogel [08:09] night duflu! [08:09] Trevinho, not yet. Only 4pm [08:10] So, as per the vmwgfx regression, as I was telling seb in one of my machine I was affected by that although not sure i did a bionic dist-upgrade, but more i upgraded to cosmic few days after release but and then to disco, but iirc this happened when switching to disco. [08:11] Who's Euan Lone talking to? [08:11] in that machine, what I've isn't anything crashing, more not showing things but the buffer per se is there. [08:11] so something lower level [08:12] yo Marcello Tonioli [08:13] duflu: as for https://gitlab.gnome.org/GNOME/mutter/merge_requests/613 I expect upstream prefers always to keep crashes around more than avoiding them, when the solution isn't the final one. [08:13] but if can replicate that? [08:14] Trevinho, I closed that and am working on an alternative. But I also explained why I disagree with crashing in this case [08:14] the only case I might think could be an issue is the case where a window isn't added to the window group actor (and thus not destroyed) or not deleted from the windows list when syncing the stack. [08:14] duflu: I know, but I expect that while we might use it as distro-patch I don't see that being accepted considering the upstream modus operandi [08:15] That's fine. It's not a critical issue and I will work toward whatever upstream prefer [08:15] for sure that foreach covers the case where windows aren't in the window group, and I should have done that before, so that's not wrong. [08:16] I agree it is correct. I was saying it's just not the only fix we should have [08:16] Trevinho, can you propose that fix too? [08:16] I also expect not to do much, in my tests I never got there with a populated list [08:16] k [08:17] Because yours might fix the root cause, but doesn't prevent regressions. Mine (and v2 of mine) also prevents regressions so we don't see it again. [08:17] We shall see how upstream feels about them [08:17] but I expect that in the sync case we're forgetting some window... Following the over-complicated logic, I can't find the issue easily, but maybe I'm missing the point where we remove the window from the list, but we never add it back to the windows list... nor destroy it (or that's not either destroyed ever) [08:18] * duflu nods [08:18] you should probably be talking in #gnome-shell ... [08:18] right :) [08:33] Laney, didrocks: are you familiar with the image build infrastructure? I'm looking at bug #1832656, trying to understand why that build failed to contact the snap store while installing the updated chromium-browser [08:33] bug 1832656 in ubuntukylin-meta (Ubuntu Eoan) "chromium-browser deb->snap transition breaks ubuntukylin image builds" [High,New] https://launchpad.net/bugs/1832656 [08:34] I suppose the build environment has restricted network access [08:34] oSoMoN: the image build has restricted network access, but can contact the snapstore [08:35] I didn't look at the bug yet, but FYI, it happens that there are glimps sometimes and the image fail to build due to network issue on the snapstore [08:35] (so, if it's a one time build failure, ignore it) [08:35] ah, but you are doing this when installing the deb [08:36] oSoMoN: did the previous build used the same deb: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/eoan/ubuntukylin/ ? [08:36] (yesterday, there was a store/network outage during image build) [08:36] didrocks, no, the previous successful build used the old deb that doesn't install the snap [08:37] yeah, that's what I see [08:37] so, the debs are installed in a chroot [08:37] which copies resolv.conf and such [08:37] I'm unsure though that it has all the settings for the snap store there [08:37] It'll be because of network access, indeed [08:37] (like snapd isn't running for instance) [08:38] in livecd-rootfs we pass SNAPPY_STORE_NO_CDN for example, that's probably important in this area [08:38] yeah, so this env variable is certainly not in the chroot ^ [08:38] I would guess that this is reproducible if you make a pkg in a PPA that has Build-Depends: chromium-browser [08:39] interesting, I'll test that [08:39] nice that you don't have to build the browser to iterate on fixes [08:40] did Stéphane avoid this for lxd by switching the seeds? [08:40] that might be more correct btw [08:41] yeah, certainly, but it would be good to figure out the problem anyway [08:41] I don' [08:41] it'll be hard to do the environment variable for only image builds [08:41] I don't know what Stéphane did, will ask him [08:46] https://paste.ubuntu.com/p/PyKKVNpnPm/ [08:46] can anyone explain this? :( [08:46] there clearly is a WantedBy there [08:47] Laney: missing reload ? [08:48] I tried a systemctl daemon-reload [08:49] yeah, so not that… [08:49] /o\ [08:49] bah [08:49] it's to do with that drop-in file [08:50] if I remove it, it works again [08:56] Laney, your guess seems correct, a PPA build cannot contact the snap store: https://launchpad.net/~osomon/+archive/ubuntu/foobar-test-chromium-browser-builddepends/+build/16944565 [08:58] oSoMoN: cool, so you can't really (easily) have such packages in build-depends [08:59] unless they do something like "if [ -e /CurrentlyBuilding ]; then export SNAPPY_STORE_NO_CDN=1; fi [08:59] I guess in the case of chromium-browser that's not really a problem, who would want to build-depend on a browser anyway? but that means that seeds need to be updated to install the snap [08:59] (package builds set that, not actually 100% sure if image ones do) [09:00] s/set that/create that file/ [09:00] would be interesting to me to know if that env var does make it work [09:02] this comment suggests that seeds were updated when lxd was transitioned to snap: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1788040/comments/12 [09:02] Launchpad bug 1788040 in OpenStack LXD Charm "Replace LXD deb by snap in Ubuntu 18.10" [Medium,Triaged] [09:36] * Laney cries [09:36] what ever is wrong with this [09:44] 380 zfs tests for grub menu generation! === CrazyMelon is now known as CrazyLemon [14:00] Hey everyone, I think I messed up my video drivers again and I can't figure out how to get it back to work. I installed slimbook (from the ppa) and powertop this morning to try and see if I could get longer battery life for my laptop (which I didn't), but now that I connected it back to power and my second monitor, it absolutely fails to recognize it [14:00] I removed slimbook and powertop already [14:02] But still, every time I was attaching the hdmi cable, the whole laptop would freeze slow and nothing else would happen. So I fired up nvidia-settings, switched the setting to the nvidia card from in there, and restarted, but still nothing [14:02] The laptop doesn't seem to freeze anymore when I plug in the monitor with the hdmi, but it doesn't appear to recognize it at all. Went in "Displays" but there's nothing there [14:03] Any idea what else could be messed up? [14:11] kenvandine, Laney, seb128, sorry, it looked for me that cyphermox has done it, I have even seen a fixed nm.py script what was missing. [14:13] It was this one giving me the confidence: https://git.launchpad.net/network-manager/commit/?h=gir-nm&id=6fb84a283f0587a894c00dcf9f13f3c35744a5d3 [14:13] tkamppeter: yeah, cyphermox said he things it's hanging in a callback [14:13] after his port [14:14] tkamppeter: we need this fixed asap [14:15] s/things/thinks :) [14:19] kenvandine, I will look into it, but I probably also do not have more GLib/gir knowledge than cyphermox. [14:21] tkamppeter: poke around and find people to ask. Maybe Laney might be able to give you some hints after you do some debugging [14:29] kenvandine, I will look into what comes out in the logs and then ask. [14:39] yeah (although I'm off tomorrow and Monday) [15:38] oSoMoN: i moved the USN refresh card for chromium to done based on the date the latest revision was published [15:38] we now have an empty list [15:38] which won't last for long :) [15:39] kenvandine, thanks, and sorry for not doing it myself. I have multiple builds of the various branches of chromium snap going, and each single build takes a long time to complete, so it's hard to tell for sure when the refresh is actually done [15:39] but at least it's being actively handled :) [15:39] no worries [15:39] :) [15:40] the list is much more for mine since i have so many to juggle [15:40] i'm just glad mine build quicker :) [16:16] cyphermox, hi [16:17] cyphermox, do you have any log from the failed nm.py after the port to gir1.2-nm-1.0? [16:18] no [16:18] it's trivial to test though, you can just run it via autopkgtest -U -s . -- qemu [16:19] cyphermox, so this is what you did and where you observed the error? [16:19] there is no error, it just hangs and eventually autopkgtest times out [16:20] cyphermox, OK. [16:24] cyphermox, thank you, I will try it. === pstolowski is now known as pstolowski|afk