14:31 <seb128> #startmeeting Desktop Team Weekly Meeting - 2020-02-25
14:31 <meetingology> Meeting started Tue Feb 25 14:31:00 2020 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
14:31 <meetingology> 
14:31 <meetingology> Available commands: action commands idea info link nick
14:31 <seb128> Roll call:  didrocks (out), duflu (out), hellsworth, jamesh (out), jibel, kenvandine, Laney, marcustomlinson, oSoMoN, seb128 , tkamppeter, trevinho, robert_ancell (out)
14:31 <hellsworth> o/
14:31 <marcustomlinson> \o
14:31 <oSoMoN> \o
14:32 <seb128> oSoMoN, don't move so far to the right!
14:32 <seb128> k, let's get started
14:32 <seb128> #topic rls-bb-bugs
14:33 <kenvandine> o/
14:33 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
14:33 <seb128> no desktop item
14:34 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
14:34 <seb128> nothing interesting there, either old/incomplete bugs or the nm ones we still didn't sort out (probably going to be easier to do in Frankfurt now)
14:34 <seb128> #topic rls-ee-bugs
14:35 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
14:35 <seb128> nothing for desktop
14:35 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-tracking-bug-tasks.html
14:35 <seb128> nothing interested there
14:35 <seb128> #topic rls-ff-bugs
14:35 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
14:36 <seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1797734
14:36 <ubot5> Ubuntu bug 1797734 in gnome-calculator (Ubuntu) "slow calculator startup" [High,Confirmed]
14:36 <seb128> I need to talk to duflu about champagne use...
14:36 <seb128> kenvandine, I guess just an untag for that one?
14:36 <kenvandine> yeah
14:36 <marcustomlinson> agreed
14:36 <marcustomlinson> not as important if it's no longer seeded
14:37 <seb128> bug #1864127
14:37 <ubot5> bug 1864127 in chromium-browser (Ubuntu) "apparmor denies ~/snap/chromium/ writes" [Undecided,New] https://launchpad.net/bugs/1864127
14:37 <oSoMoN> I need to look into that one
14:37 <seb128> I don't think there is enough data to convince me to rls track for now
14:38 <seb128> oSoMoN, should we just assign to you for investigation and revisit next week once you looked?
14:38 <oSoMoN> from a very cursory look, it sounds like a problem of the snap refreshing while running
14:39 <oSoMoN> seb128, I don't think assigning is even needed, I have the tab open and I'll request more info
14:39 <seb128> right
14:39 <seb128> ack
14:40 <seb128> bug #1864260
14:40 <ubot5> bug 1864260 in mozjs60 (Ubuntu) "TEST-UNEXPECTED-FAIL" [Undecided,New] https://launchpad.net/bugs/1864260
14:40 <seb128> looks like that was fixed, https://bugs.launchpad.net/ubuntu/+source/mozjs60/60.8.0-2ubuntu4
14:40 <ubot5> Ubuntu bug 60 in Baz (deprecated) "buildcfg should be runnable from anywhere" [Wishlist,Won't fix]
14:40 <oSoMoN> (not that I mind being assigned, but it might give a false impression that I'm acknowledging the bug before even being convinced that it's an actual problem)
14:40 <seb128> I'm closing it
14:40 <seb128> oSoMoN, right
14:41 <seb128> bug #1864274
14:41 <ubot5> bug 1864274 in firefox (Ubuntu) "crunchy pixels" [Undecided,New] https://launchpad.net/bugs/1864274
14:41 <seb128> I will ask for details on this one
14:42 <oSoMoN> or I could do it, but thanks for the offer :)
14:42 <Laney> accept then?
14:43 <seb128> Laney, I'm a bit lost of what to do from the champagne to be honest, I don't think the intend there was to raise it as a rls bug ... so yeah, I probably say rls-not-fixing?
14:44 <seb128> hopefully we can have a proper cross team discussion about those next week
14:44 <seb128> Laney, also it just reminded me I forgot to review/comment on your email draft, sorry about that!
14:44 <seb128> so -1 from me for that one/ rls-ff-notfixing
14:44 <seb128> other opinions?
14:45 <Laney> it is sort of the intent but you've argued against that multiple times now so I don't think you are minded to accept it being done this way
14:45 <Laney> maybe you want to take over proposing a process from me
14:46 <hellsworth> can we just evealuate it after the reporter provides more details/video?
14:46 <seb128> let's discuss later (probably next week?)
14:46 <hellsworth> sgtm
14:46 <kenvandine> good topic for the sprint
14:47 <seb128> I've asked for details
14:47 <seb128> right
14:47 <hellsworth> i saw that
14:47 <seb128> let's move on
14:47 <Laney> I personally think it's fine to assign to someone and let them close it if necessary
14:47 <Laney> that's a valid outcome
14:47 <kenvandine> I agree
14:47 <hellsworth> i agree with Laney
14:47 <seb128> so assign & untag?
14:48 <seb128> or tag not-fixing?
14:48 <hellsworth> assign & untag
14:48 <hellsworth> or just assign
14:48 <seb128> if we 'just assign' it's stay on the list and we see it again next week
14:49 <hellsworth> but you ask the assignee to do simething with it before then
14:49 <hellsworth> whether tag or close or w/e
14:49 <kenvandine> if we leave it tagged we can keep track of the status of all champagne bugs as they are being worked
14:49 <kenvandine> dunno
14:49 <seb128> right
14:49 <hellsworth> also, i'm the new kid so this is my naive perspective :)
14:49 <seb128> we are not likely to solve that today, let's ignore the issue for another week I say
14:49 <kenvandine> i'd say assign and leave tagged
14:50 <seb128> let's do that for this week
14:50 * Laney shrugs
14:50 <seb128> Laney, don't shrug too much, I think I'm just being lost on what the process should be for case that need info
14:51 <seb128> or maybe it's obvious and no-enough-info -> not ready to be rls accept -> notfixing
14:51 <hellsworth> we should have champagne with our champagne discussion next week 🎉
14:51 <kenvandine> +1
14:51 <seb128> anyway I don't want to make everyone waste time because I'm confused
14:51 <hellsworth> i think you're not the only one that's confused about how this tag should be used seb128
14:52 <oSoMoN> yeah, definitely not the only one
14:52 <hellsworth> so it's not wasting time to discuss it but we can better discuss it in person next week
14:52 <seb128> right
14:52 <seb128> that's an agreement
14:52 <seb128> moving on from that discussion until next week then!
14:52 <Laney> better ignore my proposed email then
14:52 <seb128> bug #1864577
14:52 <ubot5> bug 1864577 in gnome-control-center (Ubuntu Focal) "Ubuntu logo is not displayed in the 'About' Pane" [Undecided,Confirmed] https://launchpad.net/bugs/1864577
14:53 <seb128> it's minor but I think it's a regression
14:53 <hellsworth> i think we should fix it
14:53 <seb128> I would tend to vote +1
14:53 <hellsworth> +1
14:53 <kenvandine> definately +1
14:53 <seb128> kenvandine, assigned to Robert is fine?
14:53 <hellsworth> looks like low hanging fruit
14:53 <kenvandine> yes
14:53 <seb128> thx
14:55 <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
14:56 <seb128> k, nothing interesting there, the exif one is to close, nm is known, and the last one we discussed
14:56 <seb128> #topic update_excuses_by_team.html#desktop-packages
14:56 <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
14:57 <seb128> Laney, do you want to do it or should I keep that for now since I'm still active on dealing with issue for the time being?
14:57 <Laney> you can
14:57 <seb128> k
14:57 <seb128> sooo
14:57 <seb128> long list of things blocked on icu
14:58 <seb128> + now poppler and gnome-desktop transitions started
14:58 <hellsworth> icu was a dependency on many of these yesterday and was triggering a LO test that was failing because of a copy timeout in the build runner
14:58 <seb128> tjaalton, are you looking at the xorg-server issues?
14:58 * Trevinho wonders if icu would change also mozjs tests...
14:58 <Trevinho> (not for this though)
14:58 <seb128> bubblewrap/libcap is being handled, there a mp upstream now
14:59 <hellsworth> laney has increased the copy time and that improved things but the LO arm64 test was failing in a way that a retrigger has fixed for other tests so it has been retriggered and everyone cross your fingers
14:59 <seb128> Trevinho, https://bugs.launchpad.net/ubuntu/+source/mozjs60/60.8.0-2ubuntu4 was a simple fix needed for mozjs60, dunno for 68
14:59 <ubot5> Ubuntu bug 60 in Baz (deprecated) "buildcfg should be runnable from anywhere" [Wishlist,Won't fix]
14:59 <hellsworth> its weird that this list in update_excuses doesn't say that they depend on icu anymore..
14:59 <seb128> hellsworth, http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64 has failed retries from today ...
15:00 <Trevinho> ok we've that already
15:00 <seb128> yeah, I think the fact they stated what they were blocked on was a new improvement
15:00 <seb128> unsure what happened/if they rolled back or if it broke for some reason
15:00 <seb128> I will investigagte, it was useful info
15:00 <seb128> anyway
15:01 <seb128> out of those issues, we are good
15:01 <hellsworth> seb128: right and the last failure that ran for 12h is what i'm looking at. that uicheck test has failed in other tests if you scroll down - glib and python - in both cases a rerun fixed it.
15:02 <seb128> we really need an owner for gscan2pdf/arm, so please take the card if you want to volunteer
15:02 <seb128> otherwise we will probably assign someone this week
15:02 <seb128> it's block xorg-server and now the sane-backends update
15:03 <seb128> and that's it for proposed migration
15:03 <seb128> #topic AOB
15:03 <seb128> a remainer that ff is this week
15:03 <Laney> yes
15:03 <seb128> Laney, go!
15:03 <Laney> Trevinho: do you want to describe the gjs bug situation?
15:03 <Trevinho> yeah
15:04 <seb128> (while you do that, I state again that we could use help on GNOME updates)
15:04 <Trevinho> so... gjs moved to use mozjs68, gnome-shell depends on latest gjs so we had to upgrade the whole stack. Now, gjs proved to be a bit unstable while doing garbage-collection
15:04 <Trevinho> so we may have a bit more crashes...
15:05 <Trevinho> now, there's a WIP mr that aims to improve the situation and we included in debian
15:05 <Trevinho> but still there are reports of crashes, so updating to .35 would imply a more unstable desktop till we don't fix gjs
15:05 <tjaalton> seb128: yes?
15:05 <Laney> https://gitlab.gnome.org/GNOME/gjs/issues/301
15:05 <Trevinho> now... What to do? wait for the fix to land before going .35 or not?
15:05 <gitbot> GNOME issue 301 in gjs "Various GNOME Shell crashes during GC, mozjs68 regression" [1. Bug, 1. Crash, Opened]
15:05 <Trevinho> thanks L
15:06 <hellsworth> when do you think the fix will land?
15:06 <Trevinho> personally, from random usage I didn't see many issues, but....
15:06 <Trevinho> hellsworth: no clear idea, probably we may have to get the hands dirty to get a proper fix as upstream has not found a final solution yet
15:06 <Trevinho> to help*
15:07 <hellsworth> imho, i would take the safer route and wait to include .35 until the fix lands, while also trying to get it landed.
15:07 <seb128> Laney, Trevinho, what's your gut feeling?
15:07 <hellsworth> and by i, i mean you :)
15:07 <Trevinho> as said, we included https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/396 but not complete yet
15:08 <seb128> can we update gnome-shell without updating gjs?
15:08 <Trevinho> hellsworth: yeah, well... we should go past FF; so... better people to know it.
15:08 <Trevinho> seb128: we *may*.
15:08 <seb128> I should have added 'easily'
15:08 <Trevinho> yeah, it's quite easy in fact
15:09 <seb128> I would either do that
15:09 <Trevinho> we may have two choices, go with gjs 1.93.. smth, I mean the one before mozjs68
15:09 <Trevinho> *OR* just cherry-pick the required change that the shell depends on
15:09 * Trevinho blames himself for it xD
15:09 <seb128> or update including mozjs68 and use a block-proposed to stop it migrating until it gets more testing/a proper fix
15:10 <Trevinho> so using mozjs60 is still possible for a bit, but I *WON't*m suggest it for the lts, as we'd loose all the point-releases support.
15:10 <Trevinho> plus ability of cherry-picking changes from upstream
15:10 <seb128> right, I wouldn't suggest that enough
15:11 <seb128> but we need to get gnome-shell some testing
15:11 <seb128> so if it's easy I would do a first landing with mozjs60
15:11 <seb128> and then go for 68 and block that in proposed
15:11 <seb128> enough->either
15:11 <seb128> other opinions?
15:11 <Trevinho> ok, so let me try if we can just get the gjs patch out with the current gjs we've in ubuntu, and then we can try to move to the latest
15:12 <Trevinho> it should be simple enough
15:12 <seb128> k, that has my vote as step1 then
15:12 <Laney> probably ok, but testing random combinations of stuff isn't great as a rule
15:13 <seb128> right
15:13 <Trevinho> Laney: isn't a random combination in this case, because the fact is that the only reason why new gjs is needed, is because a JS definition, nothing else
15:13 <seb128> we should move to the new version whenever possible
15:13 <Trevinho> but move on as soon as possible is indeed better.
15:13 <seb128> but meanwhile there is value getting some testing of the new serie
15:13 <Laney> it is random, because gnome doesn't expect you to use parts of their old release and parts of the new one
15:13 <seb128> seeing new feature, potential UI/behaviour changes etc
15:13 <Trevinho> but being gjs just an interpreter, and being js always the same lang, there should not be any problem
15:14 <Laney> k
15:14 <seb128> your call
15:14 <Trevinho> given I'm the one who bumped that requirement upstream, I can define it not random :)
15:14 <seb128> I think getting the update based on 68 blocked in proposed should be fine as well
15:14 <seb128> :-)
15:14 <seb128> Laney, Trevinho, you got what you wanted from the discussion for now?
15:15 <Laney> sure
15:15 <Trevinho> but as you guys prefer, I mean, I'm ok with leaving a crashing desktop xD, but then I don't want to hear anybody at FRA blaming for it
15:15 <Laney> we can do it
15:15 <Laney> no guarantees though, that's likely to be a pretty untested combination
15:15 <seb128> I would advice against having an update with a known crasher landing in focal proper
15:15 <Laney> like nothing says you don't require some other fix in the new gjs for new shell
15:16 <seb128> for the reason you just stated
15:16 <Laney> but it might or even is likely to be ok
15:16 <seb128> right
15:17 <Trevinho> Laney: unless I missed something, no... Or we can actually use the *expected* version as I said, so 1.63.2 (mozjs60 based)
15:17 <seb128> well let's block in propose and do a round of in team testing first
15:17 <Trevinho> that wouldn't be random, but the one upstream requires
15:17 <Trevinho> so, as you guys prefer. But just a patch could be enough imho.
15:18 <seb128> Trevinho, you are the mainainer (upstream & downstream), do what you believe is the best :)
15:18 <seb128> k, enough on that for now, we can keep discussing after the meeting if needed
15:18 <seb128> any other topic?
15:18 <seb128> I do another round of reminders
15:18 <seb128> - we could use extra hands for GNOME updates
15:19 <seb128> - ff is thursday, land your features!
15:19 <Trevinho> - Signup at https://trello.com/b/z29JJK3q/gnome-336 for GNOME packaging :)
15:20 <Trevinho> - https://people.canonical.com/~platform/desktop/desktop-packages.html to see what's missing
15:20 <seb128> lets wrap on that note then!
15:20 <seb128> thx for the urls Trevinho :)
15:20 <seb128> #endmeeting