[02:29] <callmepk> Good morning
[02:29] <jamesh> Hi callmepk 
[02:35] <callmepk> Hi jamesh 
[04:00] <jibel> morning all
[04:04] <callmepk> Morning jibel
[04:06] <jibel> Hi callmepk
[05:27] <duflu> Morning all
[05:27] <duflu> For some :)
[05:27] <duflu> tjaalton, do you reckon Won't Fix is right for bug 1867668 ?
[05:27] <ubot5> bug 1867668 in xserver-xorg-video-intel (Ubuntu) "Visual artifacts in Gnome Shell when using the 'intel' Xorg driver" [Undecided,Won't fix] https://launchpad.net/bugs/1867668
[05:27] <duflu> If that's really the case I feel we should move toward not shipping the package
[05:51] <tjaalton> duflu: right..
[05:52] <tjaalton> it's not getting better
[06:02]  * duflu shrugs and goes to his flu shot appointment
[06:16] <tjaalton> actually, it's still needed on the oldest 64bit-capable hw, and they don't use iris so there's no corruption either
[06:19] <amurray> duflu: apologies for hijacking this but I also have the same Intel UHD 670 chipset as in that bug above, and I have xserver-xorg-video-intel installed - but I am not seeing any weird artifacts - should I also think about uninstalling that? what driver should it be using instead?
[06:28] <didrocks> good morning
[06:28] <tjaalton> amurray: you need to manually configure xorg.conf to use it
[06:42] <jibel> salut didrocks 
[06:44] <didrocks> salut jibel, ça va ?
[06:45] <amurray> tjaalton: oh so if I haven't manually configured xorg to use it, it won't be used so no worries?
[06:45] <tjaalton> right
[06:45] <jibel> didrocks, bien et toi?
[06:45] <tjaalton> modesetting_drv.so is the default where it can be used
[06:46] <didrocks> jibel: ça va
[06:47] <jibel> :)
[06:47] <jibel> cool
[07:06] <seb128> goood morning desktopers
[07:08] <didrocks> salut seb128, ça va ?
[07:08] <jibel> bonjour seb128 
[07:10] <seb128> lut didrocks, jibel, en forme ?
[07:10] <seb128> ici ça va!
[07:11] <jibel> ben oui, en forme.
[07:12] <didrocks> ça va
[07:20] <duflu> amurray, yeah your Xorg log will show which one with several messages either from "intel" or "modeset"
[07:20] <duflu> Morning didrocks, jibel, seb128 
[07:21] <didrocks> hey duflu 
[07:42] <oSoMoN> good morning desktoppers
[07:47] <duflu> Hi oSoMoN 
[07:53] <marcustomlinson> morning desktoppers
[07:54] <oSoMoN> hey duflu, marcustomlinson 
[07:56] <duflu> Hey marcustomlinson 
[08:01] <seb128> hey oSoMoN  duflu
[08:02] <Laney> hi!
[08:04] <duflu> Hi Laney!
[08:09] <didrocks> salut oSoMoN, marcustomlinson, hey Laney 
[08:10]  * Laney studies the salut/hey divide there
[08:10] <Laney> moin duflu & didrocks 
[08:13] <seb128> hey Laney, how are you?
[08:25] <Laney> yo ho seb128 
[08:26] <Laney> i'm good!
[08:26] <Laney> we did some online quizzes with friends last night where each of us created a round and then the others answered it
[08:26] <Laney> lockdown fun
[08:26] <Laney> you?
[09:37] <seb128> Laney, sorry, was afaik for a bit, things are going well here but it's getting a bit borring. The online quizzes do sound fun :)
[09:38] <seb128> shrug, I wish we had logs for build retries
[09:38] <Laney> desktop team quiz? ;-)
[09:38] <seb128> haha, we should!
[09:38] <seb128> someone has been retrying nautilus/groovy on all archs 6 times since yesterday
[09:38] <Laney> :/
[09:39] <seb128> it's not going to automagically fix itself
[09:40] <seb128> duflu, bug #1875243 sounds like a downstream issue to me, I don't think upstream has a way to declare runtime depends?
[09:40] <ubot5> bug 1875243 in gnome-control-center (Ubuntu) "Unexpressed dependency between gnome-control-center and mutter-common" [Medium,Triaged] https://launchpad.net/bugs/1875243
[09:41] <duflu> seb128, I think the problem originates upstream and it would involve us changing upstream code. But yeah I expect upstream developers won't like it and will ask we only do it downstream
[09:42] <duflu> Worth a try though
[09:42] <duflu> The G-APIs for opening schemas will crash by default when not available. I remember getting a tip from Marco a couple of years ago about how to avoid that
[09:43] <seb128> I can tell you how this one is going to go :p
[09:43] <duflu> seb128, well it's worth a try. The upstream guys are not always predictable
[09:43] <seb128> They are going to give a reply that GNOME is a coherent set and that they don't care about people trying to use g-c-c outside of a GNOME desktop
[09:44] <duflu> Yeah, as I said. But if we just propose a tiny fix that avoids crashing then maybe.
[09:44] <duflu> If nothing else it's the same fix whether we propose it upstream or avoid the discussion and patch it
[09:45] <Laney> It's not a patch, it is a package dependency
[09:46] <duflu> Laney the bug is a crash. It's "unexpressed" because it's not a package dependency
[09:46] <seb128> you could make g-c-c resilient to the missing schemas but https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/736#note_768912 is a recent statement of what upstream think about handling !GNOME use
[09:46] <duflu> Yeah, I guess they are predictable sometimes
[09:46] <seb128> 'Don't you think there are enough bugs to deal with to stop bothering with bug reports caused by folks that think that GNOME is a bag of bits from which they can pick?'
[09:47] <seb128> I expect you to get that reply as well
[09:47] <seb128> oh well, no point arguing more here
[09:47] <Laney> btw the org.gnome.mutter requirement is because of the fractional scaling patch
[09:47] <duflu> I think we've already committed more time to the discussion than the bug is worth
[09:47] <seb128> right
[09:47] <duflu> Laney, interesting then
[09:48] <seb128> Laney, that rules out the need to upstream :)
[09:48] <Laney> but the fix is the same: if you require a schema, depend on its provider
[09:49] <duflu> We don't require it. We just use it if available
[09:50] <duflu> Crashing is a poor design choice
[09:50] <duflu> as would be a dependency
[09:50] <seb128> I argued that 10 years ago when gsettings was added, but that argument is over for long now
[09:50] <seb128> no point having it again
[09:50] <duflu> Ok
[09:51] <duflu> Anyway, it was just one of a couple hundred bugs I had to catch up on. Now done. Let's see if I can catch up on MR discussions today too
[09:52] <seb128> duflu, up to you how you handle bugs but I'm going to suggest again than you don't bother re-triaging bugs other already dealt with
[09:52] <seb128> it's just not worth the effort
[09:52] <duflu> I only make changes when something is missing or wrong
[09:53] <seb128> right, when I use stock reply for crashers asking to submit them with apport and set invalid you come behind and change it back to incomplete
[09:53] <seb128> I just find that counter-productive
[09:53] <duflu> seb128, that's because it is Incomplete, not Invalid
[09:53] <seb128> it's marked invalid because submitting with ubuntu-bug will open a new report
[09:54] <seb128> and I'm not going to bother dealing with crashers without a stacktrace and submitted without the tools
[09:54] <seb128> we get those through e.u.c anyway
[09:55] <seb128> anyway, as said it's your choice at the end, it just make us waste time on each side for bugs that are not worth it
[09:55] <seb128> important segfault issues do bubble up by other means than having to pull infos from a poorly submitted report
[09:55] <seb128> at least that's my opinion
[09:56] <duflu> Sorry was AFK...
[09:56] <seb128> no worry, I don't think it's worth us entering an argument anyway
[09:56] <duflu> seb128, good point. I am the author of that stock reply and hadn't thought of it that way. I guess I only use Invalid when I expect the discussion is over. However when I use that reply generally the discussion has some way to go as the user finds the missing info
[09:57] <seb128> at a minimum we should change the stock reply then
[09:57] <seb128> 1. Look in /var/crash for crash files and if found run:
[09:57] <seb128>     ubuntu-bug YOURFILE.crash
[09:57] <seb128> Then tell us the ID of the newly-created bug.
[09:57] <seb128>  
[09:57] <seb128> should be 'mark the bug as duplicate of the new report'
[09:58] <duflu> seb128, yeah go nuts...
[09:58] <seb128> :-)
[09:58] <duflu> feel free
[09:58] <seb128> anyway, i'm going to keep closing those invalid for the reason I stated
[09:58] <duflu> OK
[09:58] <seb128> but I'm not going to fight over status, if you come after and set as incomplete I let them this way
[09:59] <seb128> I just think we have better use of our time, as said important issue will get other & proper reports
[09:59] <seb128> if a bug is reported only once, even if it's a valid problem we just don't have the resources to deal with uncommon problems at this point
[09:59] <duflu> Yes, Invalid and Invalid because Incomplete are kind of the same
[10:01] <duflu> Beware of calling them "uncommon problems" though. Plenty of times the users come through with a new bug report or a bug link and it turns out to be a duplicate of a common issue
[10:02] <Wimpress> Morning desktoppers o/
[10:02] <duflu> Morning Wimpress 
[10:04] <seb128> duflu, right, which means the issue is already reported and usually already has a debug stacktrace so we don't get value from spending time on the poor quality new report
[10:05] <seb128> which was exactly my point
[10:06] <duflu> seb128, it is useful because directing people to all share the same bug is the only way we can measure the duplicate count. Particularly important when the errors bug link isn't yet known
[10:07] <duflu> And that contributes to the bug heat to give us more accurate stats about what's hot
[10:08] <seb128> I agree with the sentiment, the problem is that launchpad is busy enough that keeping it clean could use half of the team resources
[10:08] <seb128> we just don't have the manpower to do a perfect job of it
[10:09] <duflu> I actually subscribe to fewer packages than you, so it's a smaller job from my side :)
[10:09] <seb128> I guess we slightly disagree on where we should put the cursor / how much energy we should spent on triaging and what value we get back from it
[10:09] <duflu> It's extremely important. More important than actually fixing bugs. Because you need to fix the right thing before fixing the thing right
[10:10] <seb128> I think we have a view of what needs fixing atm
[10:10] <seb128> like the nvidia scaling / screen rotation problem
[10:11] <seb128> if we dry up the release targets then we need to refine our view of what is needed next indeed
[10:12] <duflu> A full time project manager would help for sure. But most weeks are not as busy as this week so I wouldn't gauge it by this week. Just get through it
[10:13] <seb128> right
[10:48] <duflu> seb128, I am all caught up with upstreams now, except for unfinished lower priority upstream work. I expect to get back to Nvidia tomorrow. It was hard last week -- I only had a 2 day week
[10:50] <duflu> where our weeks start on Tuesdays
[10:50] <duflu> Anyway, good night
=== jhernandez_ is now known as jhernandez
[12:31] <Laney> kenvandine: did you see the image failure i fwded to you yesterday?
[12:35] <kenvandine> Laney: i did not
[12:35] <kenvandine> Laney: where?
[12:37] <Laney> oh wait there's this stupid problem where you don't get my emails isn't there
[12:37] <kenvandine> Laney: ugh... that's still a problem?
[12:37] <Laney> kenvandine: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu/
[12:37] <kenvandine> sigh
[12:37] <Laney> guess so
[12:37] <kenvandine> so weird
[12:38] <Laney> lemme send a test, tell me if you get it
[12:38] <kenvandine> - cannot use snap "gnome-calculator": default provider "gnome-3-34-1804" is missing
[12:38] <Laney> done
[12:38] <kenvandine> oh... we need gnome-3-34-1804 for 18.04
[12:39] <kenvandine> i got your test email
[12:40] <kenvandine> Laney: would it be enough to open the ubuntu-18.04 channel for gnome-3-34-1804?  Or do we need to update the seed to add that?
[12:40] <Laney> what's seeded now and what changed?
[12:41] <kenvandine> gnome-calculator uses a different platform snap now
[12:41] <kenvandine> it went from gnome-3-28-1804 to gnome-3-34-1804
[12:42] <Laney> ah
[12:42] <Laney> probably need to seed it
[12:42] <Laney> is that desirable?
[12:43] <kenvandine> it means i should update the other snaps seeded in 18.04 to use the same platform
[12:43] <Laney> two platform snaps on bionic then
[12:43] <kenvandine> so we don't end up with both
[12:43] <Laney> indeed
[12:43] <kenvandine> let me do that today/tonight?
[12:43] <kenvandine> or is this blocking anything important
[12:44] <Laney> just daily bionic builds afaik
[12:45] <kenvandine> ok, i'll work on updating those today
[12:45] <kenvandine> but need some testing too so the builds might be broken tonight too
[12:45] <kenvandine> but i'll get them all fixed asap
[12:48] <Laney> great cheers
[14:24] <hellsworth>  good morning desktopers
[14:29] <didrocks> hey hey hellsworth 
[14:29] <hellsworth> hi there didrocks 
[15:10] <jibel> bonjour hellsworth 
[15:10] <hellsworth> bonjour!
[15:57] <hellsworth> marcustomlinson, oSoMoN, kenvandine: could someone please launch some autopkgtests for me: https://paste.ubuntu.com/p/cT4CvtfTQJ/
[15:57] <hellsworth> please and thank you
[15:58] <seb128> jbicha, it's a bit of a waste to do a gnome-shell SRU for a recommends change :/ we could have coordinated to include other fixes or waiting for .2, I'm probably going to block that one in proposed until we have another upload, no point hitting users and servers twice
[16:02] <kenvandine> hellsworth: sure
[16:02] <hellsworth> thanks kenvandine 
[16:03] <marcustomlinson> hellsworth: done
[16:04] <hellsworth> ha! now they're running twice i guess
[16:04] <kenvandine> i haven't started yet :)
[16:04] <kenvandine> whew
[16:04] <hellsworth> whew
[16:04] <hellsworth> thanks marcustomlinson :)
[16:04] <marcustomlinson> :)
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[18:01] <kenvandine> oSoMoN: i just got the nifty "Chromium has been updated" notification.  Love it!
[18:10] <kenvandine> Laney: i just found your email from  yesterday in my spam
[18:10] <kenvandine> shady character
[19:07] <Laney> kenvandine: fix that build failure, and also give me your bank details
[19:13] <kenvandine> Laney: what do i have to lose!
[19:16] <oSoMoN> kenvandine, glad it works as intended! it's only a stop-gap measure though, not a proper solution to the problem
[19:19] <kenvandine> oSoMoN: yeah, eventually we'll have a user service running that will prompt and even let you trigger a restart of the app
[19:33] <ahayzen> kenvandine, assume you have seen the portal / flatpak work for this https://blogs.gnome.org/mclasen/2019/12/19/9100/  I think they were even considering putting parts of that code within gtk at one point so all apps would automagically get it, but not sure what happened to that.  Could be interesting if snap could use a similar / same portal.
[19:45] <kenvandine> ahayzen: yeah
[19:45] <kenvandine> we should start working on it soon, not sure what all pieces we'll be using to put it together
[19:50] <ahayzen> kenvandine, right, guess it also depends if you want a dialog provided by the system for all apps, or if you want an API that apps can opt into and provide their own dialogs etc
[21:55] <diddledan> not an Ubuntu Desktop question, but I'm having trouble with GTK and GStreamer (on Wayland - haven't logged out to test X11 yet).. I add a GtkGLSink Gstreamer widget to a GtkViewport in python and then try to remove it some time later. The attempt to remove immediately segfaults my app :-( after printing `(gui.py:3048628): Gdk-WARNING **:
[21:55] <diddledan> 22:37:08.114: eglMakeCurrent failed`
[21:55] <diddledan> I'm flummoxed to explain what's going on or how to fix it. advice would be helpful :-)