[07:06] <didrocks> good morning
[07:10] <duflu> o_/  didrocks
[07:12] <duflu> o_|
[07:12] <duflu> o_/
[07:19] <didrocks> hey duflu!
[08:35] <oSoMoN> good morning desktoppers!
[08:35] <duflu> Hi oSoMoN
[08:37] <oSoMoN> hey duflu
[08:39] <seb128> good morning desktopers
[08:39] <seb128> lut oSoMoN, t'as passé un bon w.e?
[08:39] <duflu> o/
[08:40] <seb128> hey again duflu :) (& didrock_s)
[08:41] <oSoMoN> salut seb128 ! très bon week-end en France, et toi?
[08:42] <seb128> moi saison des rhumes et manque de sommeil :/
[08:42] <seb128> mais sinon bon w.e et lundi ok :)
[08:43] <seb128> jamesh, hey, guess what! it's meeting reminder day :p
[08:43] <seb128> oSoMoN, ^ you too, wb :p
[08:43] <oSoMoN> right, on it!
[08:43] <jamesh> seb128: thanks.  Sorting it out.
[08:43] <seb128> thx!
[08:52] <seb128> duflu, looking to your pulseaudio merge, it's a bit weird that it doesn't include the debian/changelog new entries (those would also summarize the changes that you got merged in)
[08:52]  * didrocks learns ascii order…
[08:52] <didrocks> been wondering why a property wasn't showing up "of course, it's the first as it's a c…" :/
[08:52]  * didrocks should take more coffee
[08:53] <duflu> seb128, I forgot the convention of including the most recent one(s) from Debian.
[08:54] <seb128> duflu, no worry. Also if you did a merge it might be worth uploading to disco, it's cheap enough and it means the pacakge is green then on our reports, list of merges, ettc
[08:54] <seb128> didrocks, :)
[08:54]  * didrocks needs now to find back on how to lock a key in gsettings to test the rebase in progress…
[08:55] <duflu> seb128, how do the reports detect that? Version prefix?
[08:55] <duflu> Or just version greater...
[08:55] <seb128> duflu, compare if ... that
[08:55] <seb128> Debian version > Ubuntu version
[08:55] <duflu> Yes
[08:56] <seb128> (which is also why we usually import the debian/changelog entries and bump our version one "ubuntu1" sufix higher
[08:58] <duflu> I think we branched too long ago to include all the entries. Would just include one or two
[08:58] <duflu> But I'm also not looking at it right now. Maybe later this week
[08:59] <ricotz> good morning desktopers
[09:00] <duflu> Hi ricotz
[09:00] <ricotz> oSoMoN, hi, feel free to merge things back and forth to the firefox beta branches
[09:01] <ricotz> duflu, hey
[09:03] <Laney> yo
[09:03] <duflu> lo Laney
[09:04] <didrocks> hey Laney, ricotz
[09:05] <oSoMoN> ricotz, ack, will do
[09:05] <oSoMoN> hey Laney
[09:06] <seb128> hey Laney
[09:07]  * Laney fist bumps duflu didrocks oSoMoN seb128 
[09:07] <Laney> what's happening?
[09:09] <didrocks> not much, deep in the Shell, hoping to finish the extension story this week (or next with review time ;))
[09:09] <didrocks> you?
[09:10] <duflu> tseliot, when you're around, these are problematic in disco: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-410
[09:11] <duflu> Heh
[09:11] <Laney> also not much, seem to have fought off the cold
[09:11] <duflu> tseliot, Good morning. Also, these are problematic in disco: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-410
[09:11] <Laney> didrocks: have you been protesting? :-O
[09:12] <didrocks> Laney: heh, no ;)
[09:14] <Laney> 😈
[09:18] <seb128> duflu, you should maybe describe what's the issue with those nvidia drivers?
[09:18] <duflu> seb128, it's the same installation failure as the existing bug reports show
[09:19] <seb128> oh, I see
[09:19] <seb128> changelog being different between archs, I saw that mentioned some days ago but didn't follow
[09:20] <seb128> there was a guess that maybe it was a gzip bug
[09:23] <willcooke> oh, morning all.  Sorry, went straight in to meetings
[09:25] <Laney> moin willcooke
[09:25] <Laney> management woes
[09:26] <seb128> hey willcooke
[09:27] <oSoMoN> good morning willcooke
[09:27] <duflu> Hi willcooke
[10:33] <andyrock> morning all!
[10:35] <willcooke> hi andyrock
[11:35] <andyrock> seb128: I was working with the livepatch guys to make sure that update-manager can show the list of CVEs fixes
[11:36] <andyrock> seb128: the branch is almost ready but the change is not Backward-compatible
[11:36] <andyrock> seb128: in order to have a better transition I need to introduce a small change in update-manager and SRU it
[11:37] <andyrock> seb128: the problem is that there is no bug atm. Is it possible to SRU it anyway?
[11:46] <Deknos> hey, what is the official way to connect to an IPSEC/IKE Network with Ubuntu 18.04 Desktop?
[12:18] <oSoMoN> Trevinho, I updated https://code.launchpad.net/~osomon/ubuntu/+source/gnome-shell/+git/gnome-shell/+merge/359817 to add relevant patch tags, as you requested
[12:20] <willcooke> Deknos, I think you would be better off asking in #ubuntu - this is more of a development channel
[12:24]  * Laney screams the poppler scream of his ancestors
[12:28] <seb128> andyrock, hey, what do you mean "is not Backward-compatible", what is changing in an incompatible way and what component doesn't deal with it/what's the impacT?
[12:30] <andyrock> seb128: on newer version of livepatch (I asked them to block the change until we can properly deal with it), the "fixes" field in the yaml that we get from the /status api changed
[12:30] <seb128> andyrock, we are not consuming that file today are we?
[12:30] <andyrock> update-manager will fail to parse it and show more fixes that the real ones
[12:31] <andyrock> seb128: in update-manager we are already using the /status api
[12:31] <andyrock> the status api is not the status file used by update-notifier
[12:32] <seb128> I was not aware that we had that feature today
[12:32] <seb128> what is update-manager showing/when? is that on bionic?
[12:33] <andyrock> let me get a screenshot
[12:33] <seb128> not needed, I trust you on that
[12:33] <seb128> sorry for the questions, but we can't change that file in a way that is backward-compatible?
[12:34] <seb128> oSoMoN, best to talk to Laney for g-s reviews, Marco is off for most of decembre
[12:35] <andyrock> seb128: not easily. The sru change on our side is going to be very small
[12:35] <seb128> andyrock, the problem is not the SRU change, is assuring that people do install the update/fixed version, by experience we can't assume that's going to be the case
[12:36] <seb128> what the damage if they use the old version?
[12:37] <andyrock> they'll just get a message "Livepatch fixed X issues" instead of "Livepatch fixed Y issues" where X > Y
[12:37] <andyrock> not a huge issue
[12:37] <seb128> well, if it's misleading/wring...
[12:37] <seb128> wrong
[12:37] <seb128> man, it's 2018, why do people thing it's fine to do incompatible changes to an interface/not version those :(
[12:38] <seb128> think*
[12:38] <seb128> can't we talk the livepatch people out of being sily?
[12:38] <andyrock> I had a call today with one of them
[12:39] <andyrock> versioning is a solution is it's going to require major changes on their side
[12:39] <andyrock> *but it's
[12:39]  * didrocks nods at seb128
[12:39] <didrocks> strongly
[12:40] <seb128> come on
[12:40] <seb128> rename the file
[12:40] <seb128> how can that be "major changes"
[12:40] <andyrock> it's not a file
[12:40] <andyrock> it's a rest api
[12:40] <andyrock> http over unix
[12:40] <seb128> well, same, changing a name is probably a sed in their codebase
[12:40] <didrocks> well, at least, say "no version == v1"
[12:40] <didrocks> and then, starts at v2
[12:40] <didrocks> if this wasn't planned from the start (spoiler alert: it should…)
[12:41] <didrocks> well, same, no version in the url == v1
[12:42] <seb128> andyrock, I fail to see how that can be that complicated to version it/do what Didier is describing
[12:42] <seb128> willcooke, can we talk the livepatch team in not being sily?
[12:42] <andyrock> for complicated I mean that it will take time
[12:43] <didrocks> I guess the "more complicated" is about "then, we need to take care of changing and if we do more breaking changes, do a v2, v3, v4…" but yeah, I fail to see as well how this is complicated, it's just more work
[12:43] <didrocks> yeah, proper engineering takes time :)
[12:43] <didrocks> otherwise, this is just developping
[12:43] <andyrock> yeah but we need to deliver something before xmas
[12:44] <andyrock> willcooke: seb128 let me talk with the livepatch again and try to come out with a different solution
[12:44] <andyrock> they're not being sily, it was me that I was not clear enough about the details with them
[12:45] <seb128> k
[12:45] <seb128> thx andyrock
[12:46] <seb128> andyrock, I don't understand enough what the incompatibility is, maybe it would be ok, but it feels like non-good-engineering in any case to do that
[12:46] <seb128> and still an user visible impact even if we SRU
[12:46] <seb128> people do install from the current iso which doesn't have the fix, they are going to see the non fixed codebase the first time
[12:48] <andyrock> kk I'll talk with them
[12:49] <seb128> thx
[13:34] <willcooke> sorry was at lunch, reading
[13:37] <willcooke> andyrock, if you have another call shall seb128 and I join?
[13:38] <oSoMoN> seb128, thanks, will do
[13:40] <oSoMoN> Laney, when you have some time, would you mind reviewing and merging https://code.launchpad.net/~osomon/ubuntu/+source/gnome-shell/+git/gnome-shell/+merge/359817 ?
[13:41] <oSoMoN> in preparation for the next bionic SRU, unless there's no bionic SRU in sight, in which case it would be interesting to do one with that one patch (I can do the paperwork)
[13:46] <andyrock> willcooke: was just a quick call to get the details sorted out
[13:47] <andyrock> btw we got it sorted out
[13:47] <andyrock> thx to a mistake I did in the past this is going to be easy to do \o/
[13:47] <andyrock> willcooke: btw sure I'll invite you next time :)
[13:51] <willcooke> andyrock, sounds like you got everything sorted, thank you!  No need to invite me unless you really want to
[13:52] <willcooke> nice work andyrock
[14:14] <clobrano> hi everyone o/
[14:14] <clobrano> didrocks: I want to re-enable *-dark version release in Yaru snap
[14:14] <clobrano> For this I followed the instruction from  https://discourse.ubuntu.com/t/yaru-dark-variant/7936/3 and deleted from the .yaml files the lines where the *-dark variant was removed (both snapcraft.yaml and gtk-common-themes-parts.yaml).
[14:14] <clobrano> However, gtk2 is still the light one, unless I change something in yaru's
[14:14] <clobrano> snap/session
[14:14] <clobrano> Moreover, I expected to see Yaru-dark or communitheme-dark folders in /snap/gtk-common-themes/gtk2 snap folder, but there are only the light variants. I am surely missing something
[14:16] <didrocks> clobrano: I don't think the gtk2 thingy was wired in the build system, this surely needs work
[14:18] <clobrano> didrocks: I see, I saw that there were some "rm *-dark" in yaml, so I thought it was available
[14:19] <clobrano> ^ snap/session is the thing that made me think more. It hardcodes the path to only one gtk2 folder
[14:20] <didrocks> clobrano: yeah, I don't remember if that one is an array or a single string, worth a try
[14:20] <didrocks> clobrano: however, they won't be a second session to select dark
[14:21] <clobrano> didrocks: tried, it makes a frankenstein :D, but maybe I did something wrong
[14:21] <didrocks> clobrano: tried export GTK_SOMETHING_RC=firstpath:secondpath ?
[14:21] <clobrano> didrocks: yes, exactly that one
[14:22] <didrocks> hum, worth having a look, but if the second path exists and it doesn't work, maybe not supported by GTK2?
[14:22] <clobrano> it makes a mix of both and changing theme on tweak does nothing
[14:22] <didrocks> yeah, I think tweak doesn't read the variable
[14:23] <clobrano> didrocks: yes, I think so. I'll try to find more info on how to switch gtk2
[14:23] <clobrano> thanks :)
[14:24] <didrocks> clobrano: a fallback would be from the session startup file to read the gsettings key
[14:24] <didrocks> and adjusts as permits
[14:24] <didrocks> still won't enable to switch on the fly, but that's the best I can come up with for now
[14:24] <clobrano> didrocks: this is intersting
[14:24] <clobrano> I'll investigate more
[14:25] <seb128> didrocks, oh btw, I commented/updated the rygel MIR if you could have another look (at least to my comment), security added it to their review queue but said they would prefer a "positive opinion from the MIR team first" (like to be confident their review is not going to be wasted because the MIR is going to be denied at the MIR level)
[14:25] <didrocks> seb128: I saw, on my list for later ;)
[14:25] <seb128> didrocks, great, thx!
[14:25] <Laney> oSoMoN: yes saw the message, can do later
[14:25] <didrocks> I don't remember if the others deps were addressed
[14:26] <seb128> didrocks, not yet, I'm looking at those next but they should be easier
[14:26] <didrocks> seb128: I can only give an "ack if other deps are addressed" then, but I hope this is enough for the security team
[14:26] <didrocks> seb128: btw, I would +1 on multi-arching
[14:27] <didrocks> (so that you not wait on my format comment)
[14:27] <seb128> didrocks, k, I can spend some time on that, I just wanted to unblock security by telling them "should be fine once those packaging problems are resolved, you can review"
[14:27] <didrocks> from memory, this is what you asked (read that early this morning)
[14:27] <didrocks> yeah, I'll still have another look before doing this
[14:27] <seb128> thx
[14:27] <seb128> but agreed
[14:27] <didrocks> like the -dev and such, I don't remember why I reasked about it
[14:27] <seb128> multiarch & autopkgtest are on my list
[14:27] <didrocks> I think it's because you didn't tell which binaries would be promoted
[14:28] <seb128> right
[14:28] <didrocks> if you haven't already, maybe put the list in the description?
[14:28] <didrocks> so that when I then do the promotion, I don't have to think which ones to deal with… :)
[14:28] <seb128> will do
[14:28] <didrocks> thx!
[14:29] <oSoMoN> thanks Laney
[14:29] <didrocks> spice-webdav, you are great, but you are slow… :p
[14:29] <seb128> haha
[14:29]  * willcooke rings the bell
[14:30] <oSoMoN> is it recreation time?
[14:30] <willcooke> #startmeeting Desktop Team Meeting - 2018-12-04
[14:30] <meetingology> Meeting started Tue Dec  4 14:30:34 2018 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:30] <meetingology> Available commands: action commands idea info link nick
[14:30] <tseliot> o/
[14:30] <willcooke> Roll call: andyrock, dgadomski, didrocks, duflu (out), jbicha, jamesh (out), kenvandine, laney, oSoMoN, seb128, tkamppeter,  robert_ancell (out)
[14:31] <oSoMoN> o/
[14:31] <jbicha> o/
[14:31] <didrocks> hey
[14:31] <willcooke> This weeks updates: https://community.ubuntu.com/t/monday-3rd-december-2018/8903/5
[14:32] <seb128> hey
[14:32] <kenvandine> o/
[14:32] <tjaalton> o)
[14:33] <willcooke> Let's start with BB rls bugs:  http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:33] <andyrock> o/
[14:33] <willcooke> One added by seb128: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1798313
[14:33] <seb128> yeah, I was unsure if it's important (and I didn't know before we owned iputils :p)
[14:34] <willcooke> Yeah, I was wondering how we came to own that
[14:34] <seb128> but sounds like ipv6 tools would be good to have working in the LTS
[14:34] <seb128> probably n-m stack depedns
[14:34] <willcooke> yeah, likely
[14:34] <willcooke> I'd agree something like that low level tool should work in the LTS
[14:34] <seb128> anyway, I'm not sure it's really worth actively rls tracking but I wanted at least to raise awareness/have it mentioned
[14:35] <willcooke> Is it already on your backlog seb128?
[14:35] <willcooke> or are you looking for someone to work on it?
[14:35] <jbicha> it looks like Server has rdepends for it now. We used to have gnome-nettool in main
[14:36] <seb128> I somewhat have it on my "things to keep an eye on"
[14:36] <seb128> if someone wants to own it feel free
[14:36] <willcooke> oki, I will add it to the agenda for the next Foundations/Server meeting and see if server want to take it on
[14:36] <seb128> that said let's +1/-1 on rls tracking it?
[14:36] <seb128> I think it's too minor so -1 from me :p
[14:37] <didrocks> -1 as well
[14:37] <jbicha> personally, I'd rather let Server or whoever triage it :)
[14:37] <seb128> willcooke, let me rls-bb-notfixing it with a comment then
[14:37] <seb128> and we can try to "sell" iputils to server
[14:37] <willcooke> ack
[14:37] <kenvandine> get top dollar!
[14:38] <seb128> :)
[14:38] <willcooke> k, added to the notes for the next foundations meeting
[14:39] <willcooke> On to CC bugs:  http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[14:39] <willcooke> Nothing new
[14:39] <willcooke> Doing a quick scan of the others
[14:40] <seb128> willcooke, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=385a4886
[14:40] <seb128> ups sorry
[14:40] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[14:40] <seb128> that one has an important one
[14:40] <willcooke> stand by, just checking the other CC bugs to make sure I havent missed anything
[14:41] <seb128> ah ok, I though you forgot -dd and were done with the incoming lists
[14:41] <seb128> sorry :p
[14:41] <willcooke> :)
[14:41] <willcooke> Ok, CC tracking is in good shape.  Everything is assigned and active (even those not showing as assigned are)
[14:42] <willcooke> So now we come to DD incoming: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[14:42] <seb128> :)
[14:42] <willcooke> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1805857
[14:43] <willcooke> Who can take that one?
[14:43] <seb128> Robie has been nice enough to do debugging on the issue and believes the real problem is on the n-m tests side
[14:43] <seb128> the bug has some debugging details and an easy way to reproduce
[14:43] <seb128> I +1 to nominate it since it blocks things in proposed
[14:43] <willcooke> yeah, +1 to accept it
[14:45] <willcooke> Laney, would you be able to take a look at it?
[14:46] <seb128> he doesn't seem to be around
[14:46] <Laney> yes I am
[14:46] <Laney> guess so
[14:46] <seb128> oh, sorry
[14:47] <Laney> not that I know anything in particular about network-manager
[14:47] <willcooke> thank you Laney
[14:47] <seb128> I though I didn't see you wave or comment earlier so I assumed you were not
[14:47] <Laney> but I take my share of rls bugs :-)
[14:47] <seb128> thx Laney
[14:48] <willcooke> Nothing else for us in incoming.  There are a couple of Ubiquity related ones, one of which andyrock is already looking at and the other is a minor string change which I can probably make an MP for easy enough
[14:48] <andyrock> am I?
[14:49] <willcooke> andyrock, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1797381
[14:49] <andyrock> ah that's not real a problem with Ubiquity
[14:49] <andyrock> more ibus + gnome-shell
[14:49] <seb128> we really need to sort out those OSK issues
[14:50] <willcooke> Should that one be a rls tracked bug?
[14:50] <seb128> andyrock, let's talk about them tomorrow, I might go coworking on Carlos friday so I can talk directly with him about things that are on our list
[14:50] <willcooke> seb128 thanks, if it's not rls worthy could you untag it once you know more?
[14:50] <andyrock> seb128: kk
[14:51] <seb128> willcooke, k, well it's tagged but ubiquity is on the foundations list
[14:51] <seb128> andyrock, that one is more a gnome-shell issue though no?
[14:51] <willcooke> sure, but if the problem is elsewhere then it should probably be changed too
[14:51] <andyrock> yes it's a gnome-shell issue (or ibus)
[14:51] <andyrock> I know the problem but there is not an easy fix
[14:52] <andyrock> let's discuss it tomorrow
[14:52] <seb128> k
[14:52] <willcooke> thx
[14:52] <willcooke> Ok, on to proposed migration issues:
[14:52] <willcooke> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:52] <seb128> before we wrap bugs
[14:52] <willcooke> oops
[14:52] <willcooke> soprry
[14:52] <seb128> k, or later :p
[14:52] <willcooke> go on seb128
[14:52] <seb128> bug #1749672 is on the bb list unassigned
[14:52] <seb128> kenvandine, ^ you nominated it, can you get it assigned? to you as a default maybe?
[14:53] <kenvandine> yes
[14:53] <seb128> thx
[14:53] <kenvandine> i'll do that
[14:53] <willcooke> thx kenvandine
[14:53] <kenvandine> still waiting on security though
[14:53] <willcooke> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:54] <willcooke> Laney, do you want to do a run through? Or shall I go through them one by one?
[14:54] <Laney> i'm good
[14:54] <Laney> n-m is assigned
[14:54] <Laney> libreoffice ought to be fixed
[14:54] <jbicha> poppler is blocked by LO & xpdf https://people.canonical.com/~ubuntu-archive/transitions/html/poppler.html
[14:54] <oSoMoN> I'm looking at LO
[14:54] <oSoMoN> still struggling to reproduce locally the unit test failures
[14:55] <Laney> jbicha: i'll lead this, thanks
[14:55] <seb128> oSoMoN, any chance you get it sorted out before your long w.e?
[14:55] <oSoMoN> seb128, that's definitely my top priority
[14:55] <seb128> k
[14:55] <Laney> thx
[14:55] <Laney> so for poppler, I started looking at xpdf
[14:55] <Laney> would be good if someone can help out with other things
[14:56] <seb128> I can do the MIR for the new font depends
[14:56] <seb128> fonts-yrsa-rasa
[14:56] <Laney> yeh
[14:56] <seb128> I guess enchant/hunspell is libreoffice blocked
[14:56] <seb128> ?
[14:57] <Laney> think so, let's look at those once it is unblocked
[14:57] <seb128> k
[14:57] <Laney> just poppler and tracker for someone to help on I think
[14:57] <willcooke> cups-filters looks like its poppler again
[14:57] <Laney> yes
[14:57] <seb128> jbicha, what's the deal with tracker? are you handling that one?
[14:58] <seb128> Laney, poppler is there more needed if olivier do libreoffice and you xpdf? or did you need help on xpdf?
[14:58] <jbicha> seb128: I'm stuck on tracker, I reported the issues upstream. We could fix the autopkgtest regression if we switched back to autotools
[14:58] <Laney> dunno, I didn't analyse every package
[14:58] <Laney> the task would be partially to do that
[14:58] <Laney> and then help fix anything left over
[14:58] <seb128> Laney, k, I'm going to try to help on poppler as well and review the list
[14:59] <Laney> ty
[14:59] <willcooke> thank you chaps
[14:59] <jbicha> I believe those are the only 2 blockers for poppler really. perl needs to clean its autopkgtest queue & there are a few leaf packages to be removed like
[14:59] <jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/hunspell.html
[14:59] <seb128> on tracker I don't have a strong opinion
[15:00] <seb128> if it's not blocking other things it's probably fine to wait a bit on upstream
[15:00] <seb128> if the MIR is approved and we want to enable it in nautilus and need to unblock then we can revert to autotools
[15:00] <seb128> imho
[15:00] <seb128> or proper fix which would be even better
[15:00]  * Laney shrugs
[15:00] <Laney> I'd rather assign someone to sort it out one way or another
[15:00] <Laney> than decide now how to fix it
[15:00] <tkamppeter> willcooke, for cups-filters there came some fixes to fit it to current Poppler recently. I will soon make a new release. In general, I hope to get a GSoC student modify pdftoraster to stop using unstable Poppler interfaces.
[15:01] <willcooke> thx tkamppeter
[15:01] <seb128> andyrock, I know you are busy, do you think you could have a look to the track test issue this week or next?
[15:02] <seb128> andyrock, feel free to tell me you prefer not if you are already packed with that livepatch work
[15:02] <Laney> not sure it was that cool to switch and upload a broken version
[15:02] <andyrock> seb128: I'll take a look
[15:02] <seb128> thx andyrock!
[15:02] <seb128> and yeah, uploading something buggy and not sorting it out is not the best :/
[15:03] <seb128> I guess we covered the list now?
[15:03] <jbicha> Laney: if you're talking to me, I'm trying to run autopkgtest more before I do major uploads like the tracker meson switch
[15:03] <jbicha> I'm ok with switching it back to autotools for a bit. The meson build is less ideal for us right now anyway
[15:03] <andyrock> seb128: is there a bug somewhere?
[15:04] <andyrock> or issue
[15:05] <seb128> andyrock, https://gitlab.gnome.org/GNOME/tracker/issues/59
[15:05] <gitbot> GNOME issue 59 in tracker "functional-16-collation test failures" [Opened]
[15:05] <seb128> willcooke, Laney, AOB I guess?
[15:05] <andyrock> thx
[15:05] <willcooke> #topic AOB
[15:06] <willcooke> Anyone got anything?
[15:06] <kenvandine> nope
[15:06] <seb128> not me
[15:06] <willcooke> going once
[15:06] <andyrock> 😶
[15:06] <Laney> jbicha: yes, I think experimental & filing bugs in advance rather than breaking the 'production' suites would have been better
[15:06] <jbicha> andyrock: https://gitlab.gnome.org/GNOME/tracker/issues/61 is the other bug
[15:06] <gitbot> GNOME issue 61 in tracker "tracker-miner-fs test: Parent recursive/4 not indexed yet" [Opened]
[15:06] <Laney> i.e. I would suggest switching back
[15:07] <Laney> glib's conversion has been done well in this regard
[15:07] <Laney> sorry, didn't mean to interrupt the aob
[15:07] <willcooke> np
[15:07] <jbicha> ok, I'll switch tracker back to autotools to unblock things
[15:07] <willcooke> I think we can end here and carry on afterwards
[15:07] <willcooke> #endmeeting
[15:07] <meetingology> Meeting ended Tue Dec  4 15:07:47 2018 UTC.
[15:07] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2018/ubuntu-desktop.2018-12-04-14.30.moin.txt
[15:07] <willcooke> thanks all
[15:07] <andyrock> thx
[15:07] <oSoMoN> thanks
[15:08] <didrocks> thx
[15:08] <seb128> thx!
[15:15] <seb128> kenvandine, do you think you get give a try to the xserver ppa version from bug #1754693 to see if that fixes the issue with classic snaps on wayland?
[15:15] <kenvandine> sure
[15:15] <kenvandine> should that work in a VM?
[15:16] <seb128> thx
[15:16] <seb128> if wayland works in a VM I guess?
[15:16] <kenvandine> that's what i was wondering :)
[15:16] <Laney> does if you use qxl
[15:17] <kenvandine> i'll see what i can do
[15:19] <kenvandine> oh, the ppa is for cosmic :)
[15:19] <kenvandine> i can just test that locally then
[15:24] <seb128> Laney, just as a follow up, https://bugs.launchpad.net/ubuntu/+source/fonts-yrsa-rasa/+bug/1806712
[15:29] <Laney> nice
[15:30] <seb128> kenvandine, willcooke: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1803534/comments/11 :(
[15:31] <willcooke> urgh
[15:31] <willcooke> undo! undo!
[15:37] <ricotz> is there package which contains "xdg-dbus-proxy" yet?
[15:40] <seb128> hey ricotz, I don't know what that is and if we have a package for it
[15:42] <kenvandine> seb128: it doesn't crash
[15:42] <seb128> kenvandine, \o/, thanks for testing!
[15:42] <jbicha> xdg-dbus-proxy was split out of flatpak. I believe mcatanzaro said it would be needed for the next major webkit release
[15:43] <ricotz> seb128, it is a build-dep of webkit 2.23.x and seems to be a split-out from flatpak -- https://github.com/flatpak/xdg-dbus-proxy
[15:43] <jbicha> ricotz: I suggest talking to smcv since he's done most of the flatpak packaging so far
[15:43] <ricotz> jbicha, ;)
[15:45]  * didrocks wonders how connecting a destroy signal (without doing anything in the callback) trigger a segfault in gjs…
[15:51] <kenvandine> popey: PR submitted fixing irccloud-desktop on wayland :)
[15:58] <didrocks> interesting, the object is GC *before* the destroy signal is handled by gjs when app is closing
[15:59] <seb128> js debugging fun? ;)
[16:00] <didrocks> well js bindings debugging fun… :/
[16:37] <tseliot> Wimpress: hey, the issue you brought up about nvidia (the one on reddit) is fixed now (or, rather, worked around): https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-410/+bug/1804738
[16:40] <Wimpress> tseliot: Thanks!
[16:40] <tseliot> :)
[18:08] <willcooke> night all
[22:37] <jbicha> ximion: hi, I guess we're supposed to have appstream metadata for system-installed GNOME Shell extensions
[22:37] <jbicha> https://gitlab.gnome.org/GNOME/gnome-tweaks/merge_requests/25
[22:37] <gitbot> GNOME issue (Merge request) 25 in gnome-tweaks "extensions: Fix opening system installed extensions in gnome-software" [Opened]
[22:37] <jbicha> do you want me to open an asgen bug?
[22:39] <ximion> jbicha: the appstream metadata that GNOME extensions uses does not follow the standard at all and introduces a new toplevel component type of "shell-extension" that will never ever be added to the specification. Even hughsie agrees that it was a mistake to implement this, and that the GNOME Shell extensions should really be of type "addon" and extend "org.gnome.Shell".
[22:40] <ximion> I could think about allowing something in that converts the metadata trsnaparently to how it actually should look like, but then the data wouldn't be of much use. I also don't want to add the component type to the AppStream reference implementation
[22:41] <jbicha> addon makes sense
[22:41] <ximion> so, ideally the metadata would just be standard-compliant and use AppStream's addon system properly - AFAIK the only thing this hasn't been done yet is lack of someone doing the work, as well as legacy compatibility issues
[22:43] <jbicha> I'm thinking we should open a bug somewhere so that can be documented
[22:43] <ximion> yes, probably
[22:43] <ximion> I also think it's a solvable issue, but it just hasn't been a high enough priority yet
[22:44] <ximion> hughsie and I actually want to reduce the delta between GNOME's AppStream and the spec, this shell-extension stuff is a quite significant piece
[22:45] <ximion> (and a bit frustrating, since it wouldn't have needed to exist in the first place)
[22:45] <jbicha> I'd been wondering why shell extensions UI didn't work well (when linked to from Tweaks). I didn't realize until now that it works better in Fedora
[22:45] <jbicha> https://gitlab.gnome.org/GNOME/gnome-software/issues/222 was my original bug
[22:45] <gitbot> GNOME issue 222 in gnome-software "shell-extensions: [3.25.91] --details incorrectly shows extension as available instead of installed" [Bugzilla, Closed]
[22:46] <jbicha> do we want the bug in Launchpad or somewhere else?