[00:51] <kenvandine> robert_ancell: thanks
[06:54] <tjaalton> jibel: hi, would you mind testing the bionic xserver update for bug 1792932
[06:54] <ubot5> bug 1792932 in xorg-server (Ubuntu Xenial) "Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed." [High,Confirmed] https://launchpad.net/bugs/1792932
[07:08] <didrocks> good morning
[07:12] <duflu> Morning didrocks and tjaalton
[07:12] <duflu> tjaalton, I have finished verifying the Bluetooth fix thanks. Just can't update the bug because of prolonged Launchpad timeouts
[07:13] <didrocks> hey duflu
[07:14] <Wimpress> Morning o/
[07:15] <duflu> Morning Wimpress
[07:15] <didrocks> hey Wimpress
[07:16] <Wimpress> duflu: A community member contacted me about a bug they've prepared a fix for.
[07:16] <Wimpress> Could you cast an eye over it?
[07:16] <Wimpress> https://bugs.launchpad.net/xorg-server/+bug/1776447
[07:16] <ubot5> Ubuntu bug 1776447 in xorg-server (Ubuntu) "Xorg's Indirect GLX broken from upstream regression" [Undecided,Confirmed]
[07:17] <duflu> Great. Though I know very little of Xorg's internals
[07:17] <Wimpress> It is a one line patch. In fact a revert that upstream made yesterday.
[07:18] <tjaalton> Wimpress: I prefer to work with git
[07:18] <tjaalton> and there are other pending fixes
[07:19] <tjaalton> duflu: cool
[07:19] <duflu> Wimpress, yeah I was about to say that. I guess the patch tagging needs improving and we don't need to review it further other than to consider the severity of the issue. tjaalton can roll it into an update
[07:23] <duflu> Extra nice that the author of the offending commit now calls it bogus
[07:23] <duflu> So there's no debate
[07:26] <oSoMoN> good morning desktoppers
[07:26] <duflu> Hi oSoMoN
[07:26] <oSoMoN> hey duflu
[07:27] <didrocks> hey oSoMoN
[07:27] <oSoMoN> salut diddledan
[07:27] <oSoMoN> grrrr
[07:27] <oSoMoN> salut didrocks
[07:29] <didrocks> :p
[07:29] <didrocks> you should use weechat with smart nickname completion!
[07:32] <ogra> salut diddlerocks :)
[07:35] <didrocks> :p
[07:36] <duflu> Maybe not... https://en.wiktionary.org/wiki/diddle
[07:44] <didrocks> definitivelly not :)
[07:45] <duflu> It's nice to learn something about music though
[08:27] <seb128> goooood morning desktopers
[08:28] <duflu> Morning seb128. How goes?
[08:29] <seb128> hey duflu, I'm good thanks, what about you?
[08:29] <duflu> seb128, I'm good. Getting excited about what can be achieved for 20.04 performance but I won't speak too soon till it's real and the code is finished
[08:30] <seb128> great :)
[08:32] <didrocks> salut seb128
[08:33] <seb128> lut didrocks, comment ça va ?
[08:38] <didrocks> ça va, en train d’écrire des tests, comme d'hab
[08:38] <didrocks> :p
[09:54] <marcustomlinson> morning desktoppers
[10:02] <duflu> Morning marcustomlinson
[10:03] <mitya57> clobrano: Hi, I want to make a new yaru-theme upload to fix bug 1853768. What do you prefer: a new upstream tag based on master, or cherry-pick the needed changes on top of 19.10.5?
[10:03] <ubot5> bug 1853768 in yaru-theme (Ubuntu) "Qt apps, like kid3-qt, which uses legacy icons "document-*.png", show them as normal document icon under Yaru theme" [Undecided,Confirmed] https://launchpad.net/bugs/1853768
[10:04] <mitya57> (Or I should ask someone else?)
[10:06] <clobrano> hey mitya57, I think that current master has some updates we want to show in 20.04 first, so for me the cherry-pick is a good option, if possible, but about new release asks Laney, didrocks and seb128 opinions first :)
[10:08] <mitya57> Thanks for response. I want uploads for both Focal and Eoan (for Eoan, after the current version in -proposed migrates).
[10:09]  * mitya57 waits for the mentioned people's opinion
[10:12] <didrocks> hey marcustomlinson
[10:12] <didrocks> I’m unsure SRUing is something that will help a lot (time for the release to get done and so on)
[10:12] <didrocks> for focal, shouldn’t we just release master, once ready?
[10:16] <mitya57> didrocks: for focal, I'm fine with master, just want to know when it will be “ready”.
[10:16] <mitya57> for eoan, it's not a problem for me to do the SRU, there are several affected apps and I have seen complains about this bug in some upstream bugtrackers too.
[10:17] <seb128> hey marcustomlinson, how are you today?
[10:17] <didrocks> mitya57: I think clobrano will decide when they want to prepare for a worthy and stable release :)
[10:17] <seb128> mitya57, eoan already has a SRU in proposed that needs to clear off first
[10:18] <mitya57> seb128: I saw that, that’s why I said “after the current version in -proposed migrates” above.
[10:18] <seb128> ah, right
[10:19] <mitya57> But indeed, if that version takes a long to migrate, then the fix for Eoan will be less important. But now there are still 3 months before Focal release so I consider it important.
[10:20] <didrocks> ack, let's see once the current one migrate
[10:20] <mitya57> Ok, I will wait then and ask again later if needed.
[10:20] <seb128> you can probably SRU another version with the icon fixes
[10:21] <seb128> to replace the current one
[10:21] <mitya57> That may delay migration of gnome-shell/mutter so I will better wait.
[10:22] <Laney> moin
[10:22] <mitya57> Looking at bug 1857037, it still needs verification
[10:22] <ubot5> bug 1857037 in yaru-theme (Ubuntu Eoan) "Update to 3.34.2 and SRU it" [Undecided,Fix committed] https://launchpad.net/bugs/1857037
[10:23] <Laney> indeed it does!
[10:23] <marcustomlinson> seb128: ill :(
[10:23] <mitya57> hi Laney!
[10:24] <seb128> marcustomlinson, oh :-( get better!
[10:24] <seb128> hey Laney
[10:24] <marcustomlinson> seb128: will try to walk it off :P
[10:24] <mitya57> Trevinho: ↑ re 1857037, is this an oversight or you want more testing?
[10:24] <didrocks> hey Laney
[10:24] <seb128> Laney, how are you? recovered from the travel?
[10:25] <duflu> Morning Laney
[10:25] <Laney> mitya57: anyone can do verification, doesn't have to be the uploader
[10:26] <Laney> so yes, you can help if you want or maybe Marco will get to it soon
[10:26] <Laney> hey seb128 didrocks duflu
[10:26] <Laney> mostly recovered but my face hurts a bit now, silly dentists
[10:26] <mitya57> Ok, I will test it in a few days if nobody beats me to it.
[10:26] <Laney> how's it going here?
[10:26] <seb128> doing good! I recovered as well, still coughing a bit though :-/
[10:26] <Laney> :(
[11:03] <ricotz> hello everyone
[11:03] <ricotz> seb128, thanks \o/
[11:04] <didrocks> hey ricotz
[11:12] <Trevinho> mitya57: mh no it's fine... I wanted to keep both as saying we're releasing the two
[11:15] <mitya57> Trevinho: I see you marked it as verified now, thanks!
[11:15] <Trevinho> np
[11:18] <diddledan> morning
[11:18] <Laney> Trevinho: need to do the other bugs to release mutter and shell
[11:18] <Laney> there's that red one too
[11:20] <Laney> also HI!
[11:20] <Trevinho> Laney: hi :)
[11:20] <Trevinho> Laney: yeah, i've looked at others too, the red one is probably not a regression so need to talk with SRU team
[11:21] <Laney> yeh, maybe just comment on it explaining the situation and fix the tag
[11:21] <Trevinho> also e.u.c is still garbage :(
[11:22] <Laney> :(
[11:27] <Trevinho> things like https://launchpad.net/bugs/1853357 I've no way to verify... :/
[11:27] <ubot5> Ubuntu bug 1853357 in mutter (Ubuntu Eoan) "display (whole computer?) hangs when I attempt to use DisplayLink with Wayland" [Medium,Fix committed]
[11:28] <Laney> if the fix was from upstream you don't need to per the exception
[11:28] <Laney> xnox: I wonder if we can de-hardcode the 20.04 in your cdimage branch
[11:29] <Laney> e.g.
[11:29] <Laney> In [6]: focal.version
[11:29] <Laney> Out[6]: u'20.04'
[11:29] <Laney> ?
[13:37] <xnox> Laney:  i was thinking the same. But i don't know if we will be installing oem-20.04 for the whole 5 years, or if we will need to change it to something else. And if in gutsy we will have oem-20.04 or oem-20.10 =/
[13:37] <xnox> Laney:  i guess the question is if gutsy will have oem-20.04 or oem-20.10
[13:38] <Laney> do we have oem kernels for non-ltses anyway?
[13:38] <Laney> man I'm hungry, going to go eat my egg and cress sandwich
[13:38] <Laney> let's talk shortly :-)
[13:39] <xnox> Laney:  so, we did in bionic-focal time, they were copied up.
[14:54] <Laney> xnox: but the versions revved or?
[15:01] <xnox> Laney:  binary copy up
[15:02] <xnox> so identical versions
[15:04] <Laney> hmm
[15:04] <Laney> i'm just worried we will lose track of updating this until something breaks
[15:17] <hellsworth> good morning desktopers!
[15:30] <didrocks> hey hellsworth
[15:31] <hellsworth> hi didrocks ! how's life?
[15:36] <kenvandine> good morning hellsworth
[15:37] <hellsworth> hi kenvandine !
[15:39] <Laney> xnox: https://paste.ubuntu.com/p/WQxgtRcH6d/ ?
[15:39] <Laney> hey hellsworth
[15:40] <Laney> https://paste.ubuntu.com/p/tvw2kTK7Hm/
[15:42] <hellsworth> sup Laney !
[15:50] <didrocks> hellsworth: busy with tests (& headaches :p)
[15:51] <hellsworth> aww i'm sorry to hear that but you can do it! your day is almost over :)
[15:52] <didrocks> thx :)
[15:58] <kenvandine> oSoMoN: you have some experience with autostart in a snap right?
[16:07] <kenvandine> oSoMoN: i asked for a review from you on https://gitlab.gnome.org/Community/Ubuntu/gnome-software/merge_requests/12
[16:07] <gitbot> Ubuntu issue (Merge request) 12 in gnome-software "snap: Autostart application service" [Opened]
[16:08] <oSoMoN> kenvandine, not really, but I can give it a review, once I'm done with my current task
[16:11] <kenvandine> oSoMoN: ok, i would appreciate it
[16:11] <kenvandine> it was my first time handling autostart
[16:17] <RikMills> is anyone looking at merging alsa-utils? alsa-lib 1.2.1 in proposed has breaks on alsa-utils < 1.2.1 so breaks 1.1.9.in release
[16:17] <RikMills> ^ seb128 perhaps ;)
[16:17] <seb128> doko, ^ you did sync that version
[16:21] <RikMills> not urgent, but I noticed a couple of testers on a forum complaining of uninstalability. wtf they are doing running with proposed enabled, I don't know!
[16:22] <seb128> yeah, unsure why people opt in for it :/ maybe they do for SRU testing and then upgrade to a non stable serie and still have it? (or do we make the dist-upgrade comment out proposed in such cases? if we don't we should)
[16:22] <Laney> I would bet you people want the 'latest' stuff
[16:22] <seb128> :(
[16:36] <Laney> DMB nominations
[16:36]  * Laney looks at seb128 and didrocks ;-)
[16:36] <seb128> lol
[16:38] <RikMills> Also people on forums say 'all seems fine with proposed', so others try it. Often with desktop systems running a small subset of the archive, it might be fine for long periods. So small group confirmation bias sets in
[16:38] <RikMills> until it all goes BANG
[16:39] <Laney> we should upload viruses up there every so often
[16:40] <Laney> https://www.youtube.com/watch?v=2uaYcnFQF-g
[16:43]  * didrocks unsure that will be sane in term of $TIME :p
[16:44] <xnox> Laney:  looks good! push it.
[16:44] <xnox> Laney:  on top of my branch, or instead of it? but i guess you do want the python2 fixes that are in my branch too
[16:44] <Laney> xnox: that was on top of your branch anyway
[16:44] <Laney> let me push that somewhere and you can merge, then we merge the combined thing, or something
[16:45] <Laney> I mean assuming the logic is right
[16:45] <Laney> maybe we should check with apw
[16:45] <xnox> Laney:  apart from i don't have commit rights =)
[16:45] <xnox> Laney:  maybe we should double check with apw.
[16:46] <Laney> which one of the 1000 terminal tabs was that in...
[16:46] <Laney> ah found it
[16:49] <diddledan> Duflu, re: the new crash caused after the fix in LP #1776447, there's a new upstream fix that I'll test in about 4 hours from now when I'm back at a computer. If it works I'll update the debdiffs with the newer change and ping you again
[16:49] <ubot5> Launchpad bug 1776447 in xorg-server (Ubuntu) "Xorg's Indirect GLX broken from upstream regression" [Medium,Triaged] https://launchpad.net/bugs/1776447
[16:50] <diddledan> Aah, duflu isn't in here atm
[16:50] <Laney> xnox: I suppose the other idea is to only include oem-xx.yy for lts series eh? or do we want to do this for interim releases too?
[16:50]  * diddledan pongs wimpress instead just to say hi 😜
[16:51]  * Laney wibbles at diddledan 
[16:51] <Laney> Daniel's good at reading bug traffic so probably commenting on Launchpad is as good a way to reach him as any
[16:51] <diddledan> Wibblin wot sits, Batman!
[16:51] <diddledan> Gotcha
[16:53] <xnox> Laney:  i have no idea
[16:54] <xnox> Laney:  surely we can revisit this during 20.10 cycle. And when 20.10 opens, it will contain a copy-up oem-20.04
[16:54] <Laney> I guess so
[16:54]  * Laney is trying to guard against forgetting to do this
[16:54] <Laney> seen that enough times :(
[16:55] <xnox> yes.....
[16:55] <tjaalton> enablement is only done on lts
[16:55] <xnox> Laney:  also not sure what to do in livecd-rootfs, cause it has -20.04 hardcoded there. I guess invoke ubuntu-disto-info-data thing to query the last known lts?
[16:56] <xnox> tjaalton:  but the oem kernel flavour does and must exist in intermediate releases.
[16:56] <xnox> tjaalton:  because, at least in the past, none of the metapackages rolled off to generic kernel in the intermediate releases
[16:56] <Laney> xnox: same logic I guess
[16:56] <Laney> but in shell, good luck with that /o\
[16:56] <xnox> tjaalton:  linux-oem exists in cosmic, disco, eoan
[17:04] <Laney> xnox: bzr merge lp:~/ubuntu-cdimage/dynamic
[17:04] <tjaalton> xnox: does exist yes
[17:04] <Laney> wait does .format() exist in python 2?
[17:04] <Laney> In [1]: "{}".format("foo")
[17:04] <Laney> Out[1]: 'foo'
[17:04] <Laney> yes
[17:05] <Laney> make that 'bzr merge lp:~laney/ubuntu-cdimage/dynamic' unless you are me
[17:17] <tjaalton> seb128: mesa git master still broken on s390x (all big-endian perhaps?)
[17:36] <tjaalton> there's also https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2443 which should prevent this from happening in the future
[17:36] <gitbot> Mesa issue (Merge request) 2443 in mesa "WIP: ci: Add cross-build tests for mips, ppc64el, and s390x" [Ci, Opened]
[17:36] <tjaalton> once it's done
[17:44] <xnox> Laney:  pushed.
[17:47] <xnox> tjaalton:  commented to state that there is native s390x executors on travis.
[17:49] <tjaalton> ah, cool
[19:39] <seb128> tjaalton, k, so what's the next step to unblock the update? bisecting the commit that broke it?
[20:09] <robert_ancell> seb128, still around?
[20:13] <seb128> robert_ancell, yes
[20:13] <robert_ancell> seb128, quick question about g-c-c, are you familiar with the privacy panel patches?
[20:14] <seb128> robert_ancell, which ones specifically?
[20:14] <robert_ancell> The privacy panels have been radically relayout, and I'm wondering how to integrate the connectivity switch (which panel?), the whoopsie control (which panel?) and the "hide buggy controls" (still applicable?)
[20:15] <robert_ancell> connectivity-switch.patch privacy-panel-whoopsie.patch and ubuntu_privacy_hide_buggy_controls.patch
[20:15] <robert_ancell> I'll go to mpt next but I thought you might have some history on these.
[20:16] <seb128> robert_ancell, well, connectivity is only an extra toggle, https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/348 for discussion/history
[20:16] <gitbot> GNOME issue (Merge request) 348 in gnome-control-center "privacy: add network connectivity checking toggle" [1. Feature, 2. Needs Design, 6. Component: Privacy, Opened]
[20:16] <seb128> I've not seen the new design, probably best to check with mpt where it fits
[20:16] <seb128> maybe it's own subpanel?
[20:17] <robert_ancell> Yeah, I was thinking that we might have to add a subpanel or two.
[20:17] <kenvandine> good morning robert_ancell
[20:17] <robert_ancell> kenvandine, hi
[20:17] <seb128> robert_ancell, whoopsie ... didn't upstream have support for abrt (the fedora tool)?
[20:17] <seb128> -  self->abrt_row = add_row (self, _("Problem Reporting"), self->abrt_dialog, GTK_WIDGET (w));
[20:17] <seb128> +  self->abrt_status = GTK_LABEL (gtk_label_new (""));
[20:17] <robert_ancell> seb128, seems to be gone in the new privacy layout.
[20:18] <seb128> :(
[20:18] <seb128> one for mpt then I guess
[20:18] <robert_ancell> oh, wait. Yeah, there it is.
[20:18] <seb128> robert_ancell, and "hide buggy control" probably still apply
[20:19] <seb128> robert_ancell, the micro/camera control only apply to flatpaks (and maybe snaps) which means you deny access to the camera ... but cheese (installed as a deb) still use the camera
[20:19] <robert_ancell> seb128, so hide the whole camera/mic subpanels?
[20:19] <seb128> which makes it look buggy
[20:19] <seb128> I would say yes
[20:19] <seb128> unless ^ is resolved
[20:19] <seb128> or that at least the wording hints that only some applications respect this setting
[20:19] <robert_ancell> Hmm, perhaps we can patch in a label.
[20:20] <seb128> (but then it's more confusing than useful and it's tricky to convey which applications)
[20:20] <seb128> iirc mpt hinted that it was not really possible to describe what applications in a way user would understand
[20:20] <seb128> "debs still have access" -> what is deb?
[20:20] <seb128> "how do I check"
[20:20] <robert_ancell> yeah
[20:21] <robert_ancell> Life is terrible mid-transition.
[20:21] <seb128> imho we have better things to work on, I would just keep distro patching it out
[20:21] <seb128> well, it's more that GNOME doesn't accomodate for the real world :p
[20:21] <robert_ancell> troll :P
[20:21] <robert_ancell> OK, thanks! I just wanted a high level view of these patches. I'll go to mpt for more answers.
[21:02] <tjaalton> seb128: probably, I'd need to figure out how to get a vm instance on bos02
[21:22] <robert_ancell> jamesh, did you ever propose your whoopsie changes upstream to g-c-c?
[22:22] <seb128> tjaalton, do you really need that? the openscad test were enough to reproduce the bug for me on a bos01 s390x instance, no need of a vm/working graphical session
[22:28] <seb128> robert_ancell, it's not friday, no trolling, but that example is a typical. Those controls don't act on most available/used apps, nothing prevent a random app to be written and bypass the setting, they are misleading at best (you could argue they are security material, users could trust the setting real avoid access to their camera/microphone which it doesn't)
=== JanC is now known as Guest16482
=== JanC_ is now known as JanC