13:31 <willcooke> #startmeeting Desktop Team Weekly Meeting - 2018-10-02
13:31 <meetingology> Meeting started Tue Oct  2 13:31:59 2018 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
13:31 <meetingology> 
13:31 <meetingology> Available commands: action commands idea info link nick
13:32 <seb128> :)
13:32 <willcooke> Roll call: andyrock, dgadomski, didrocks, duflu (out), jbicha, jamesh (out), jibel/heber, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out), tjaalton, tseliot
13:32 <seb128> hey
13:32 <andyrock> o/
13:32 <didrocks> o/
13:32 <kenvandine> \o
13:32 <tseliot> o/
13:32 <oSoMoN> o/
13:32 <jibel> o/
13:32 <willcooke> New format this week then everyone.  You should have had a chance to review people's updates.  I've had no messages for anyone in far away places that they want to raise any topics.
13:33 <heber> o/
13:33 <jbicha> o/
13:33 <willcooke> #topic Round table
13:33 <willcooke> By a show of hands, does anyone have anything they want to raise based on the updates from the rest of the team, or otherwise?
13:33 <willcooke> i.e. if no one wants to talk about anything, then we can move on to rls bugs
13:33 <tjaalton> o/
13:34 <didrocks> just that I'm fighting with gsconnect extension
13:34 <didrocks> upstream is really responsive
13:34 <didrocks> I hope to upload a new snapshot soon
13:34 <willcooke> tjaalton, is that "I want to talk about something" or just a "I'm here!"?
13:34 <didrocks> it will still be in universe, but if people want to give a test
13:34 <willcooke> didrocks, that's great to hear, thanks!
13:34 <tjaalton> willcooke: I'm here :)
13:34 <didrocks> the idea is that the code will be close to what we want to ship by default next cycle
13:34 <Laney> better
13:35 <didrocks> so, the earlier you test with your phone, the better :)
13:35 <seb128> just for next time, maybe standardize on a round of "o/ I've a topic"
13:35 <didrocks> that's it for me
13:35 <seb128> then we can go round between those who said that
13:35 <seb128> with the chair giving the turn to each
13:35 <seb128> otherwise it's going to be cahos
13:35 <willcooke> that's what I was going for here
13:35 <didrocks> seb128: +1
13:35 <seb128> willcooke, right
13:35 <Laney> NM's definitely being crashy here too, took me a while to get online after rebooting just then
13:35 <seb128> but tjaalton did an unclear o/
13:35 <seb128> and didrocks just wrote
13:36 <didrocks> yeah, better to standardize
13:36 <jbicha> o/
13:36 <seb128> lol
13:36 <seb128> see jbicha also :p
13:36 <willcooke> I have a question as well
13:36 <willcooke> ok, let's start with jbicha
13:36 <willcooke> #topic jbicha
13:36 <seb128> was that a raise of hand or an "hey"?
13:36 <jbicha> I had a tracker question but it was late so maybe discuss that on the community site?
13:37 <seb128> we can discuss it now
13:37 <seb128> imho
13:37 <jbicha> ok: https://community.ubuntu.com/t/tracker-stuck-in-cosmic-proposed/8224
13:37 <jbicha> can we fast track the tracker mir?
13:38 <seb128> no
13:38 <didrocks> didn't we just discuss how bad the idea of fast tracking the tracker mir ?
13:38 <kenvandine> gotta track the tracker
13:38 <seb128> security team has some backlog, we have no impact on that, and in fact we are more import MIRs we want to get through (portals)
13:38 <jbicha> didrocks: sorry, I might have missed that discussion
13:38 <seb128> and it's not a good idea to add a feature that late
13:39 <didrocks> on the MIRing side, this is my view:
13:39 <didrocks> jbicha: the tracker code is very different than the one we used to have in main
13:39 <didrocks> and as I have written, I already have doubt security-wise on file permissions
13:39 <jbicha> ok, maybe I'll talk to mbiebl about letting the package split in
13:39 <didrocks> I don't think telling "double guessing what the MIR team applied and bypass security" is a good option
13:39 <seb128> would need a ffe at least
13:39 <seb128> I would be fine deleting the new tracker from cosmic-proposed
13:39 <seb128> it didn't migrate out and we don't need that update
13:39 <seb128> but if you have an easy fix that works too
13:40 <seb128> it's getting a bit late to land a new version now (having it not migrated out of proposed yet means it virtually haven't landed/got testing)
13:40 <jbicha> let's see if the split works, otherwise I'm fine with dropping it from -proposed
13:40 <seb128> wfm
13:40 <jbicha> /next topic
13:40 <willcooke> cool, thanks. We know where we're going then
13:40 <willcooke> #topic willcooke
13:41 <willcooke> tjaalton, I'm keen to hear if you're any closer to understanding why virtualbox machines won't start without nomodeset
13:41 <willcooke> That's a release blocker for me
13:42 <tjaalton> willcooke: the kernel driver init takes 25-30s on initial boot, probably because the driver is not in the installer initrd
13:42 <tjaalton> this triggers a weird race in xserver which has been there for some time already
13:42 <seb128> "probably because the driver is not in the installer initrd"
13:43 <seb128> how can we get that "probably" out of the sentence?
13:43 <jibel> has the vbox driver already been in the installer initrd?
13:43 <seb128> that
13:43 <seb128> and if it was, when/why has it been removed?
13:43 <Trevinho> seb128: is not according to lsinitrd
13:43 <jibel> and if it was not why is it failing now?
13:43 <Trevinho> lsinitramfs
13:44 <Trevinho> maybe we're faster in doing something else and thus....
13:44 <Trevinho> the issue.
13:44 <Trevinho> like we try to start x when things are not ready yet, while before this was delayed by something else. This sometimes happen.
13:44 <seb128> $ lsinitramfs /boot/initrd.img-4.4.0-116-generic | grep virtual
13:44 <seb128> lib/modules/4.4.0-116-generic/kernel/drivers/regulator/virtual.ko
13:44 <seb128> on xenial
13:45 <seb128> so it was in the initramfs
13:45 <Trevinho> as per listing initrd there's no x11 related video drivers there
13:45 <seb128> or is that a different one?
13:45 <didrocks> lib/modules/4.18.0-8-generic/kernel/drivers/regulator/virtual.ko
13:45 <didrocks> it's still in the initramfs
13:45 <tjaalton> seb128: vboxvideo
13:45 <seb128> didrocks, wrong name, sorry :p
13:45 <seb128> tjaalton, that was not in xenial either
13:45 <didrocks> this one is not, was it in xenial?
13:45 <didrocks> ok
13:45 <Trevinho> yeah, no video driver is there iirc
13:45 <andyrock> is it possible to add it and test  if it works?
13:46 <tjaalton> seb128: maybe X started later then
13:46 <Trevinho> ah, some are.
13:46 <seb128> tjaalton, but the foundamental issue is an xorg one right?
13:46 <Trevinho> but just lowlevel fb stuff
13:46 <tjaalton> there's a window of like 3s.. X starts at 25s (here), vboxvideo init done at 27s
13:47 <tjaalton> Trevinho: huh? my initrd has all from drivers/gpu/drm
13:47 <Trevinho> tjaalton: oh, yeah... sorry. Not vbox though
13:47 <tjaalton> vbox is in staging
13:48 <seb128> I'm not sure that discussion is actually productive working toward a resolution
13:48 <willcooke> tjaalton, is this issue on your radar? Are you activly looking in to it?
13:48 <seb128> tjaalton, is a team owning the problem/actively working on resolving it?
13:48 <willcooke> Do you need something from us to help?
13:49 <seb128> and which team does/should own it
13:49 <tjaalton> I don't know how to fix this
13:49 <seb128> ?
13:49 <seb128> well, what changed compared to bionic
13:49 <seb128> is the vboxvideo init slower?
13:49 <Trevinho> Also, this is related also to the one on kvm with std driver, isn't it?
13:49 <Trevinho> while it has a different way of applying, but might be related to the same xorg issue in not trying better to reload or what?
13:50 <seb128> tjaalton, is that a kernel regression? like does it work using the bionic kernel?
13:50 <tjaalton> Trevinho: somewhat, but it's fixable by enabling drm/bochs
13:50 <tjaalton> seb128: I don't know
13:50 <Trevinho> gdm-wise we could change something as trying to load things for more time or what?
13:50 <Trevinho> reload*
13:50 <seb128> k
13:51 <seb128> I suggest that's not a topic that's going to be resolved in the meeting
13:51 <seb128> it needs actual debugging and understanding of the problem
13:51 <Trevinho> well, at least to have a pointer I mean...
13:51 <Trevinho> not details, but a direction.
13:51 <willcooke> Yeah, seb128, jibel - lets chat about how we can try and get more of an understanding about what's going on later on
13:51 <seb128> that's 10 min we are on the topic and I don't feel like we got anything useful out of it
13:51 <willcooke> /next topic
13:52 <tjaalton> seb128: testing an older kernel would mean building the installer image with cosmic userland
13:52 <willcooke> tjaalton, we can chat more about this after the meeting
13:53 <tjaalton> sure
13:53 <willcooke> We're not going to solve it now
13:53 <willcooke> thanks
13:53 <willcooke> I dont think anyone else had any topics, so we can move on to rls bugs
13:53 <Trevinho> well
13:53 <Trevinho> I've few branches for review and I'd like to get the SRU on XUbuntuCancel for search provider in, so reviews would be appreciated. There's also a silo to test and in case to publish in seconds if all fine
13:54 <Trevinho> so... just an heads up on that. Ah, and also a gnome-calculator fix.
13:54 <willcooke> Links are in your post on the hub right Trevinho?
13:54 <Trevinho> yep
13:54 <willcooke> thx
13:54 <seb128> k
13:54 <Trevinho> I wanted to mention in the 1st part but I didn't know how things were organized yet :)
13:55 <Trevinho> and suddently topic changed :)
13:55 <willcooke> ok, any more before we review rls bugs?
13:55 <andyrock> o/
13:55 <willcooke> #topic andyrock
13:56 <andyrock> I got 2-3 MPs in salsa
13:56 <andyrock> they have been there for a while
13:56 <andyrock> is anyone willing to review them?
13:56 <andyrock> not sure it fit here
13:56 <seb128> I can help with some
13:56 <andyrock> kk thanks I'll send you the links later
13:56 <willcooke> thx
13:56 <Laney> two things
13:57 <Laney> #debian-gnome is better for debian sponsoring
13:57 <Laney> and I don't know that using this round for "please review my stuff" is good
13:57 <Laney> (that is feedback)
13:57 <andyrock> kk thanks
13:57 <seb128> andyrock, duflu usually list the things he's waiting for sponsoring in his update, I think that's a good place
13:57 <seb128> I try to unblock things he has listed
13:57 <andyrock> makes sense
13:57 <andyrock> thanks for the feedback
13:57 <seb128> I would have done the same for yours (in fact I spotted the g-c-c one and have a tab opened on it)
13:57 <seb128> yw
13:57 <seb128> Trevinho, ^ you as well
13:58 <Trevinho> indeed
13:58 <seb128> but yeah, similar to Laney
13:58 <seb128> I think we derailed the purpose
13:58 <seb128> those "those needs <...>" should be in the summaries
13:58 <willcooke> +1
13:58 <seb128> or we recreate a round table of updates on IRC
13:58 <willcooke> let's do that for next week
13:58 <willcooke> /next topic
13:58 <Trevinho> no, no... that's fine to define a strategy here and then we follow in the updates.
13:58 <willcooke> any one else?
13:58 <seb128> can we do rls now? ;)
13:59 <willcooke> yes
13:59 <seb128> thx :)
13:59 <Trevinho> Since we had not, better to define one
13:59 <willcooke> #topic Release Bugs
13:59 <seb128> right
13:59 <willcooke> Ok, we're going to skip the rls-bb-tracking bugs this week only, because the list is very long and Seb wants to spend some time tidying it up before we review
14:00 <willcooke> rls-bb-incoming is empty (enough)
14:00 <willcooke> so rls-cc-incoming first, why not
14:00 <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
14:00 <willcooke> 1 issue: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1795421
14:00 <ubot5> Ubuntu bug 1795421 in gnome-control-center (Ubuntu) "[cosmic] sidebar requires scrolling" [Low,Confirmed]
14:01 <willcooke> Nice to have but not a blocker IMO
14:01 <seb128> rls-cc-notfixing imho
14:01 <seb128> it's a minor cosmic issue
14:02 <seb128> we should fix it but it's not a release blocker
14:02 <willcooke> 2 votes for notfixing
14:02 <willcooke> anyone opposed?
14:02 <willcooke> going once
14:02 <willcooke> twice
14:03 <willcooke> gone
14:03 <willcooke> bug updated and commented
14:03 <willcooke> rls-cc-tracking now:
14:03 <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-tracking-bug-tasks.html
14:04 <willcooke> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1794280
14:04 <ubot5> Ubuntu bug 1794280 in xorg-server (Ubuntu Cosmic) "gdm doesn't start on a fresh installation of Cosmic Desktop" [Critical,Confirmed]
14:04 <didrocks> this is the vbox issue?
14:04 * didrocks opens
14:04 <willcooke> I think that might be the same bug I saw earlier and is fixed in proposed afaict
14:04 <willcooke> didrocks, no, different thing
14:04 <Trevinho> didrocks: not only, also on kvm..
14:04 <jibel> this is qemu and hw
14:04 <Laney> Marco got assigned that bug last week, it's a different task on the same one
14:05 <Trevinho> yep, I've spent time in debugging, but something gdm specific, is as the vbox one something related to the init
14:05 <willcooke> Trevinho, so WIP still?
14:05 <Trevinho> so... not much desktop stuff, unless we decide to change gdm way of starting up
14:05 <seb128> Trevinho, on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1794292/comments/11 (which is linked) you wrote "the patch should be fine", what patch is that?
14:05 <ubot5> Ubuntu bug 1794292 in plymouth (Ubuntu Cosmic) "plymouthd crashed with SIGSEGV in /sbin/plymouthd:11 in ply_renderer_set_handler_for_input_source -> ply_keyboard_stop_watching_for_renderer_input -> ply_keyboard_stop_watching_for_input -> ply_device_manager_deactivate_keyboards -> on_deactivate" [High,Confirmed]
14:06 <Laney> different bug?
14:06 <Trevinho> seb128: as per https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1794292/comments/10
14:06 <seb128> that doesn't have a patch :p
14:07 <Trevinho> seb128: https://launchpad.net/ubuntu/+source/plymouth/0.9.3-1ubuntu9
14:07 <seb128> Laney, could be, it's unclear to me, sounds like we are conflicting vbox/plymouth/other issues
14:07 <Trevinho> yep... these are two different things
14:07 <seb128> anyway
14:07 <seb128> that should be assigned to Trevinho, as Laney said that was the outcome from the previous meeting
14:07 <seb128> so let's do that and move on?
14:07 <willcooke> Trevinho, can you update the bug pls?
14:07 <seb128> we can discuss technical details after the meeting if needed
14:07 <Trevinho> seb128: as said, not really much i can do on that...
14:08 <willcooke> k, lets talk about it more later
14:08 <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1794951
14:08 <ubot5> Ubuntu bug 1794951 in gnome-calculator (Ubuntu Cosmic) "Calculator (snap) is slow to start on a freshly installed Cosmic machine" [High,Confirmed]
14:08 <Trevinho> I had this assigned, but I marked the gdm as invalid. So I can assign to myself if you want me to look at other places I don't know exaclty
14:08 <willcooke> I raised that one, but having spoken to Ken earlier today there are other more important things and that issue is probably not a release blocker
14:08 <Laney> looks like that one skipped the process :P
14:09 <willcooke> so I'm happy to untag
14:09 <willcooke> Laney, yeah I should have incoming that one, sorry
14:09 <Trevinho> willcooke: fixing that would be quite easy though, it's just few lines of snapcraft if he's busy It takes few minutes.
14:09 <willcooke> kenvandine, could you chat to Trevinho about that? ^
14:09 <kenvandine> yeah
14:09 <willcooke> Trevinho, I'm not so sure, but would be interesting to see
14:10 <willcooke> next:
14:10 <willcooke> http://launchpad.net/bugs/1792932
14:10 <ubot5> Ubuntu bug 1792932 in xorg-server (Ubuntu Cosmic) "Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed." [High,Triaged]
14:10 <willcooke> Thats the virtualbox bug which we already talked about
14:10 <willcooke> next: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1743216
14:10 <ubot5> Ubuntu bug 1743216 in xdg-utils (Ubuntu Cosmic) "perl crashed with SIGABRT in _dbus_abort()" [High,In progress]
14:10 * Trevinho is pretty sure this and 1794292 are two different faces of the same medal
14:10 <willcooke> Looks like it might be fixed already, but is in progresss
14:10 <Trevinho> [previous one]
14:11 <seb128> the fix is in the queue yes
14:11 <seb128> needs to be approved by someone from r-t (other than L_aney)
14:11 <willcooke> I can validiate that one I think
14:11 <willcooke> next: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1785240
14:11 <Laney> it's fine, that one is on track
14:11 <ubot5> Ubuntu bug 1785240 in gnome-software (Ubuntu Cosmic) "Cancelling snapd authorization triggers error notification" [Low,In progress]
14:11 <andyrock> is this really a release blocker?
14:11 <andyrock> :)
14:12 <andyrock> btw the fix is upstream (both in gnome-software, snapd-glib, and snapd)
14:12 <andyrock> in cosmic Robert needs to take care of gnome-software
14:12 <andyrock> the rest has already been uploaded
14:13 <willcooke> yeah not a release blocker
14:13 <andyrock> not so much I can do also because I don't understand how Robert deals with gnome-software uploading
14:13 <willcooke> the last one is a security issue:
14:13 <willcooke> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1788929
14:13 <ubot5> Ubuntu bug 1788929 in evince (Ubuntu Bionic) "Debian/Ubuntu AppArmor policy gaps in evince" [Undecided,Triaged]
14:13 <willcooke> and that's the end of the list
14:13 <seb128> looks like jd_strand is on it
14:14 <willcooke> Any comments on rls bugs before we move on?
14:14 <didrocks> nope
14:14 <seb128> no
14:14 <willcooke> ok, moving on
14:14 <willcooke> #topic Trevinho
14:14 <willcooke> Trevinho, you had something you wanted to raise
14:15 <Trevinho> yeah, as per SRU of mutter/gnome-shell to bionic... despite the upstream pings it looks like a point version for 2.28 is taking ages
14:15 <Trevinho> there are still some relevant issues like http://launchpad.net/bugs/1727356 that should be pushed
14:15 <ubot5> Ubuntu bug 1727356 in mutter (Ubuntu Bionic) "Login screen never appears on early generation Intel GPUs (Core2 and Atom etc)" [High,Triaged]
14:15 <Trevinho> but waiting for a stable...
14:15 <seb128> I'm not sure that's a team topic?
14:16 <Trevinho> I'm happy to cherry-pick, but... should I go with that or what?
14:16 <seb128> like it's fine to have as a channel discussion with me/your usual sponsors at any time
14:16 <seb128> no?
14:16 <Trevinho> I want to know how to proceed...
14:16 <seb128> right
14:16 <seb128> I'm just saying you don't need the full team attention for that
14:16 <seb128> let's discuss it out of the meeting?
14:16 <Trevinho> ok, as you prefer.
14:17 <willcooke> ok, last topic:
14:17 <willcooke> #topic AOB
14:17 <willcooke> Anyone got anything?
14:17 <Laney> I'd be interested to know who is still watching now
14:17 <andyrock> o/
14:17 <Laney> after all this format was less boring
14:17 <Laney> :-)
14:17 <didrocks> o/
14:17 <jibel> I am
14:17 <Nafallo> I'm mostly confused :-)
14:18 <Trevinho> 👀
14:18 <seb128> o/
14:18 <willcooke> Comment: we need to find a better way than waiting for "anyone... anyone... Bueller"
14:18 <seb128> less boring, but that one didn't feel as smooth as I was expecting
14:18 <oSoMoN> o/
14:18 <Laney> yes indeed
14:18 <seb128> I guess that's normal for a first try though
14:18 <Laney> where can we give our Useful Feedback™?
14:18 <didrocks> seb128: agreed
14:19 <oSoMoN> gotta get used to the new format, I like the new format with a post on the hub a lot more
14:19 <didrocks> (is it time to list those who didn't answer that they are following? :p)
14:19 <seb128> same
14:19 <seb128> Laney, feedback here or by reply to willcooke's email I would say?
14:19 <seb128> willcooke, ^ wdyt?
14:20 <andyrock> lol
14:20 <Laney> ok
14:20 <Laney> I'd prefer rls tracking updates in the status posts themselves
14:20 <Laney> that bit disrupted the flow a lot for me and I think could have been done offline
14:20 <seb128> me too, at least for the -tracking review part
14:20 <willcooke> was just typing, yeah, I think email is right, then we dont generate noise here waiting for everyone's feedback
14:20 <seb128> I didn't really understand why we did/did it this way
14:20 <Laney> and getting into the discussion of bug details should be avoided more imho, but that's not a new issue
14:20 <Laney> otherwise I like it more
14:21 <seb128> like most are assigned, post ff we used to just have people listing their bugs in a section with the status of each
14:21 <willcooke> ok, please summarise your feedback via email and next meeting will the FTW
14:21 <willcooke> *be
14:21 <seb128> Laney, yeah, we keep falling back into discussing the issues :/
14:21 <seb128> :)
14:21 <seb128> thx!
14:22 <willcooke> So we still need to talk more about the virtualbox issue
14:22 <Laney> eom?
14:22 <seb128> wrap?
14:22 <seb128> we also need to talk to Trevinho about his SRUs :)
14:22 <willcooke> just checking if there was anything else we still need to talk about
14:22 <willcooke> that
14:22 <willcooke> ok, EOM
14:22 <willcooke> #endmeeting