[06:17] <jibel> morning everyone
[06:24] <duflu> Morning jibel
[08:28] <seb128> gooood morning desktopers!
[08:29] <Mirv> mornings. do you have plans to switch to Enchant 2 in 20.04, or a plan not to switch? it's been a few years in coming to Debian/Ubuntu.
[08:30] <Mirv> (I'd guess no at this point, and that's just fine)
[08:31] <duflu> Hi seb128 and Mirv!
[08:31] <seb128> hey duflu, how are you?
[08:31] <Mirv> hey duflu
[08:31] <duflu> seb128, going well, finally getting back into Mutter after the BlueZ adventure. You?
[08:31] <seb128> duflu, sorry for hijacking your flicker bug to request that kernel option, seems to have turned into a confusing process for you fighting with the kernel team workflow
[08:32] <Wimpress> Morning o/
[08:32] <seb128> duflu, I'm good!
[08:32] <seb128> hey Wimpress, how are you? ready for design hackfest?
[08:32] <duflu> Hi Wimpress
[08:32] <duflu> seb128, I don't know what you mean so shall wait for the bug mail
[08:32] <duflu> Oh, right, flicker-free boot
[08:32] <seb128> Mirv, bigon was looking at it on the Debian side before the holidays iirc, would probably be good to switch ... do you know what other distributions are doing in that regard?
[08:32] <duflu> No problem. We agreed the change was good. Just also keep the bug open
[08:33] <seb128> duflu, I should have opened a new bug to request the option in retrospect
[08:34] <duflu> I didn't want to go as far as to reject the kernel update with verification-failed so expected it
[08:37] <Mirv> seb128: yes it landed to sid + focal on holidays. Fedora has switched, openSUSE did not switch to Leap 15 or 15.1, but seems to have mostly in this Tumbleweed (Inkscape still pulls in Enchant 1 as well)
[08:37] <Mirv> hello Wimpress
[08:38] <seb128> Mirv, ah, good, well then we can do the transition now :-)
[08:40] <seb128> bigon, hey, happy new year! now that enchant-2 is in unstable, do you plan to migrate $things to it?
[08:50] <bigon> seb128: hey, happy new year to you too. I'm was just looking at empathy right now, before going to $work (and.. I'm late already)
[08:50] <bigon> it's already fixed in webkit git
[08:51] <seb128> bigon, no hurry, I was just wondering if there is anything blocking or if we should transition things as we update them ... sounds like we can transition, thx!
[08:51] <bigon> there are 3 packages that would require an update to the last version of gspell at the same time to avoid loading enchant(1) and enchant-2 in the same binary
[08:52] <bigon> there is some (tiny) porting to do as they removed the deprecated functions
[08:52] <seb128> ah, good point
[08:52] <seb128> I can have a look to that transition if you want
[08:53] <seb128> let me know, I don't want to dup work you already plan to do
[08:53] <bigon> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947979 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947930
[08:54] <seb128> cool
[09:02] <Laney> moin moin moin
[09:03] <duflu> Morning Laney
[09:03] <Mirv> bigon: hmm actually correcting my above Fedora statement, it seems Fedora 31 does install also enchant 1 still, even though only used by ibus-typing-booster, which depends on python3-enchant they haven't migrated to enchant-2. also similar to openSUSE Tumbleweed installing Inkscape brings in enchant 1 as well.
[09:04] <didrocks> hey hey
[09:04] <Mirv> (playing around on live DVD)
[09:04] <Mirv> hey Laney & didrocks
[09:05] <seb128> hey Laney, didrocks, how are you today?
[09:05] <bigon> Mirv: main applications like evolution, gnome-builder, ... are already supporting both at build time
[09:05] <bigon> for the other the porting is not looking too hard at 1st glance
[09:07] <Mirv> yes it seems distro world is 90%+ migrated but dual install still the norm a bit like long time with python 2+3.
[09:13] <Laney> hey duflu Mirv didrocks and bigon
[09:13] <Laney> seb128 left so he doesn't get a hi
[09:14] <Laney> didrocks: all settled in ok?
[09:17] <didrocks> hey Mirv! Long time no see :)
[09:18] <didrocks> Laney: yeah, thanks! After some (un-well-rather-)expected hurdles in the way, arrived ok, just later than planned
[09:19] <Laney> :(
[09:19] <Laney> but glad you made it
[09:19] <Laney> are the yaru people there already?
[09:19] <Laney> say hi from me!
[09:20] <didrocks> yeah, they are around. I'll pass the hello once Wimpress finishes the intro ;)
[09:33] <Laney> wb & hi seb128
[09:35] <oSoMoN> good morning desktoppers!
[09:36] <oSoMoN> happy new year!
[09:42] <duflu> Morning oSoMoN, happy new year
[09:42] <oSoMoN> hey duflu
[09:49] <seb128> hey oSoMoN, bonne année, how were the holidays? had a good year start?
[09:50] <oSoMoN> seb128, bonne année! the year started well indeed, I'm rested and I've enjoyed a lot of family time. How are you?
[09:50] <seb128> oSoMoN, same here!
[09:53] <seb128> duflu, you should probably gave up on bug #1836858 , use it as a repurposed for the kernel config change and re-open a new one
[09:54] <seb128> duflu, the bug reference is included in the changelog of a SRU that got accepted, the tooling and process are not flexible and I doubt they will reupload a kernel only to change the bug reference
[09:54] <duflu> seb128, that would be technically incorrect and maybe even more confusing. I'm happy to keep reopening and clarifying it
[09:54] <seb128> rather than fighting bots and processes it's easier to just reopen a bug imho
[09:54] <duflu> The bots will stop soon
[09:55] <seb128> duflu, well, I screwed and renamed/repurposed your bug wrongly to be about the kernel config option, so my mistake, but what is technically right doesn't matter much at this point
[09:55] <seb128> either we keep creating issues over the status or just accept that bug got handled wrongly, repurpose and re-open one
[09:56] <duflu> seb128, my other motivation is that we already have the community subscribed to that bug. I would rather not have to explain it to them and move to a new one
[09:56] <seb128> or we keep creating problem for us, kernel team and SRU teams by fighting over tags & status
[09:56] <seb128> k, well at least tag it verification-done to not block the kernel SRU then
[09:56] <bigon> Laney: hey
[09:57] <seb128> duflu, the verification-failed tag will block the SRU as invalid which we really don't want
[09:57]  * duflu untags
[09:57] <seb128> thx
[10:04] <seb128> oSoMoN, chrisccoulson, bug #1854363 looks like something that might be worth a follow up bionic upload since it a regression from the previous security update?
[10:06] <oSoMoN> I haven't checked whether the fix has been released yet, and if it does fix the problem, but the upstream bug report isn't marked fixed
[10:07] <Laney> hey oSoMoN, happy new year
[10:07] <oSoMoN> hey Laney, how was your holiday?
[10:08] <Laney> quite nice thanks, had family here for a bit, visited other family and then went to Wales for the new year!
[10:08] <Laney> played a lot of mario kart there :>
[10:10] <oSoMoN> cool
[11:30] <Trevinho> Buon anno! :)
[11:40] <oSoMoN> good morning Trevinho, happy new year!
[11:40] <Trevinho> you too oSoMoN
[11:42] <tomreyn> happy 2020 desktoppers!
[11:47] <tomreyn> there's something that i (being distant from the development processes) just do not understand - maybe you canhelp me get a better understanding: there are those fatal problems people keep facing during desktop installations, which seem to have not been tackled in years. why is this (this is not criticism, i'm trying to understand)?
[11:50] <tomreyn> well you probably have so much to do with the standard tasks, this will be why. but, maybe it's worth holding back on the regular work for a while and focussing installation problems.
[12:22] <tomreyn> Sorry for spamming your channel, I wrote this up here in a more readable way. https://www.writeurl.com/publish/96unbxhadua3b6s05a9c
[12:46] <jibel> tomreyn, for 1. it's been discussed on https://discourse.ubuntu.com/t/defaulting-to-verify-the-image-integrity-before-installing-on-desktop/13472
[12:49] <jibel> and happy 2020 to you too :)
[12:50] <tomreyn> thanks for both, jibel
[12:52] <jibel> for 2. it's very hard to know in advance if grub will fail to install on a specific user setup. I agree that triaging and classifying grub reports is useful to identify patterns and fix installation issues. any help welcome but it requires a fair amount of expertise to do such triage.
[12:56] <tomreyn> once it's clear where grub will write to, a test write could take place, and the result examined, this could happen early during the phase of the installation where no more user input is possible.
[12:57] <tomreyn> this would already provide a much better UX than having to wait throughthe installation (which can still take long on old hardware) and have it end with "grub failed, have a nice life."
[12:57] <tomreyn> i guess this is not a verbatim quote ;-)
[12:58] <jibel> but then it's already too late and too early at the same time. At this point the disk has already been formatted, filesystem is being copied and you need the target filesystem to be populated to install grub on it.
[13:00] <jibel> I admit the error message is a bit dry and user friendliness could be improved
[13:00] <tomreyn> my point there is you'd not need to have the user sit it out.
[13:00] <tomreyn> a nicer error message, hinting on what to do next, could also help, yes.
[13:06] <tomreyn> a unfortunately not uncommon support scenario is a user who has at long last made the decision to move over from windows, owns a single usb stick which currently contains the ubuntu installer (and possibly not the latest version of it), had the installer overwrite any reaminders of windows, and then runs into this message at the very end of the installation.
[14:29] <hellsworth> good morning desktopers!
[14:29] <kenvandine> Good morning
[14:30] <oSoMoN> good morning hellsworth, kenvandine
[14:30] <oSoMoN> and happy new year!
[14:30] <hellsworth> hi! and happy new year :)
[14:30] <seb128> good morning U.S
[14:30] <seb128> #startmeeting Desktop Team Weekly Meeting - 2020-01-07
[14:30] <meetingology> Meeting started Tue Jan  7 14:30:40 2020 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:30] <meetingology> Available commands: action commands idea info link nick
[14:31] <seb128> Roll call:  didrocks (off), duflu (off), heather, jamesh, jibel, kenvandine, laney, marcustomlinson (out), oSoMoN, tkamppeter (out), trevinho, robert_ancell (out)
[14:31] <oSoMoN> o/
[14:31] <seb128> happy 2020, I hope everyone had nice holidays
[14:31] <kenvandine> o/
[14:31] <Laney> yo
[14:31] <hellsworth> \o
[14:32] <seb128> k, let's get started
[14:32] <seb128> #topic rls-bb-bugs
[14:32] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:32] <seb128> bug #1854363
[14:32] <seb128> that's a regression for the update uploaded to security before the holidays, I tagged it
[14:33] <seb128> it's not going to impact most users but still it's a LTS regression and has been reported
[14:33] <seb128> I vote +1 to accept it :)
[14:33] <oSoMoN> sounds reasonable
[14:33] <seb128> oSoMoN, thx
[14:34] <seb128> since we have the maintainer agreement, let's move on!
[14:34] <seb128> bug #1855893
[14:35] <seb128> it's an oem team request and seems reasonable
[14:35] <seb128> I vote +1 to accept it
[14:35] <seb128> other opinions?
[14:35] <hellsworth> seems like a reasonable suggestion
[14:35] <hellsworth> +1
[14:36] <seb128> thx, moving on then
[14:36] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[14:37] <seb128> the only unassigned one are the NMs ones we said we would discuss in another meeting but didn't do yet
[14:37] <seb128> I'm going to skip that
[14:37] <seb128> I'm also going to skip disco at this point, doesn't make sense to upload new SRUs for that serie now
[14:38] <seb128> #topic rls-ee-bugs
[14:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
[14:38] <seb128> no desktop entries
[14:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-tracking-bug-tasks.html
[14:39] <seb128> some leftover triaging, I will deal with those after the meeting
[14:39] <seb128> #topic rls-ff-bugs
[14:39] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:39] <seb128> no desktop ones
[14:40] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:40] <seb128> only n-m there as well to triage
[14:40] <seb128> #topic update_excuses_by_team.html#desktop-packages
[14:40] <seb128> update_excuses_by_team.html#desktop-packages
[14:40] <seb128> ups
[14:40] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:40] <seb128> Laney, your turn
[14:41] <Laney> thx
[14:41] <Laney> one second, browser is being sad
[14:42] <Laney> ok
[14:42] <Laney> there's a few for tjaalton in there, assuming those are being handled or will be after this ping ;-)
[14:43] <Laney> so evolution-data-server (ftbfs) fonts-smc (mir?) brotli (i386 something) libxcb (something) pcsc-lite (dunno)
[14:43] <seb128> I did the font MIR this morning
[14:44] <seb128> I can do libxcb it's another test that need crossarch use of pkg-config/gcc
[14:44] <Laney> that looks like the normal thing
[14:44] <hellsworth> what do you do about the ones that are here because of regressions?
[14:44] <Laney> I will take the brotli one and ping LocutusOfBorg about pcsc-lite since he synced it
[14:44] <hellsworth> do they sit here until the regressions have been fixed?
[14:44] <Laney> yeah
[14:45] <Laney> but those xorg/mesa ones are for Timo
[14:45] <seb128> I would argue e-d-s should be fixed by vorlon since he broke it by doing i386 hacks, I will ping him
[14:45] <Laney> ok, I didn't know if he just got unlucky being the next uploader
[14:45] <seb128> tjaalton, ^ please confirm that you at looking at those
[14:45] <Laney> already did ping him a second ago, no need to pile on
[14:46] <Laney> anyway someone pls take the font one
[14:46] <seb128> k
 I did the font MIR this morning
[14:46] <hellsworth> i'll take a look at fonts-smc
[14:46] <hellsworth> oh right
[14:46] <Laney> ah cool thx
[14:46] <hellsworth> what about pcsc-lite?
[14:46] <seb128> https://bugs.launchpad.net/ubuntu/+source/fonts-smc-gayathri/+bug/1858620
[14:46] <Laney> I was going to ping the person who synced it and see if they will look
[14:46] <hellsworth> makes sense
[14:47] <hellsworth> if you hit a dead end with that person, i'm happy to take a look
[14:47] <seb128> sounds like we are good for this round then
[14:47] <hellsworth> i wanted to mention libmail-dkim-perl
[14:47] <seb128> oh, snapd-glib ftbfs also, unsure if that's for Robert
[14:47] <tjaalton> seb128: if you mean xserver/mesa/glvnd landing on focal, yes
[14:47] <seb128> tjaalton, thx
[14:48] <kenvandine> seb128: looks like a flaky test in snapd-glib
[14:48] <seb128> kenvandine, maybe retry it then?
[14:48] <kenvandine> i kicked a rebuild a few minutes ago and it looks like it passed
[14:48] <seb128> ah ok
[14:48] <seb128> nice
[14:48] <hellsworth> both libmail-authenticationresults-perl and libscalar-list-utils-perl ahve been looked at by the security team and suggest they are accepted. i'm not sure what further steps there are to actually get them in.
[14:48] <kenvandine> well... "nice"
[14:48] <kenvandine> hate flaky tests
[14:48] <seb128> right
[14:48] <Laney> file a bug about it?
[14:49] <Laney> in general I don't look at those greyed out ones, (1) in case things sort themselves out, (2) to give people a chance to do it themselves without being hassled
[14:49] <seb128> @perl MIR, it looks like the MIR team/cpaelzer were fine with those
[14:49] <Laney> looks like people don't agree with that policy?
[14:50] <hellsworth> seb128: right so what's the next step to get them into main?
[14:50] <cpaelzer> ?
[14:50] <seb128> but maybe ping cpaelzer about it on #ubuntu-devel just to know if he consider those as +1 now
[14:50] <seb128> cpaelzer, sorry, I forgot you were there :)
[14:50] <cpaelzer> I'm trying to be everywhere
[14:51]  * Laney looks under the sofa
[14:51] <cpaelzer> trying to ...
[14:51] <seb128> cpaelzer, https://bugs.launchpad.net/ubuntu/+source/libmail-authenticationresults-perl/+bug/1853175 got a +1 from security team, we were wondering if that need to bounce back to you to gave the final +1 next?
[14:51] <cpaelzer> checking ...
[14:51] <seb128> cpaelzer, and https://bugs.launchpad.net/ubuntu/+source/libscalar-list-utils-perl/+bug/1854849
[14:51] <seb128> thx
[14:51] <seb128> k
[14:51] <seb128> Laney, I think we can call it done for that section of the meeting?
[14:51] <hellsworth> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libscalar-list-utils-perl/+bug/1854849 too
[14:52] <Laney> ok
[14:52] <seb128> thx
[14:52] <seb128> @topic AOB
[14:52] <seb128> #topic AOB
[14:52] <Laney> would be good to consider my previous comment
[14:52] <seb128> anything else to discuss today?
[14:52] <cpaelzer> seb128: Both had the MIR Team ack already
[14:52] <seb128> Laney, sorry I didn't see your question earlier, crossed discussions
[14:52] <hellsworth> Laney: I agree that the grey ones might sort themselves out so not looking at them until they become bold makes sense to me
[14:52] <cpaelzer> seb128: and if we wollow the little state chart onhttps://wiki.ubuntu.com/MIRTeam#Process_states
[14:53] <cpaelzer> that means after security ack (which we got) they are good to go
[14:53] <cpaelzer> If the changes are already in proposed that pulls things in "Fxi Committed"
[14:53] <seb128> cpaelzer, k, that chart has them as "fix commited" when they are good o go so I was unsure
[14:53] <cpaelzer> if the changes are not there yet "In Progress"
[14:54] <hellsworth> oh ok thank you very much!
[14:54] <cpaelzer> security Team doesn't want to change states, so we have to clean them up after their reviewed most of the time
[14:54] <seb128> Laney, but yeah, ignoring the grey ones makes sense to me
[14:54] <seb128> they are often in flux indeed
[14:54] <seb128> cpaelzer, k, which is what made me unsure/to ping :)
[14:54] <cpaelzer> well done :-)
[14:54] <seb128> cpaelzer, thx for clarifying
[14:55] <cpaelzer> hellsworth: so set the state whatever matches the current upload state
[14:55] <cpaelzer> and once things show up in component-mismatches (which might be now already) get the attention of your favourite AA
[14:55] <hellsworth> what is an AA?
[14:55] <hellsworth> sorry, i'm new here :)
[14:55] <kenvandine> archive admin
[14:56] <cpaelzer> thanks kenvandine
[14:56] <seb128> k
[14:56] <Laney> they can execute the move to main
[14:56] <hellsworth> ok
[14:56] <cpaelzer> hellsworth: from this chat the closest AA to ask might be seb128 :-)
[14:56] <seb128> right :)
[14:56] <hellsworth> oh ok cool :)
[14:56] <seb128> I will have a look after the meeting
[14:56] <seb128> any other topic?
[14:56] <kenvandine> my favorite AA :)
[14:56] <cpaelzer> oh meeting - then sorry to interrupt - cpaelzer out
[14:57] <seb128> lol
[14:57] <seb128> cpaelzer, to be fair we are the ones who summoned you :)
[14:57] <seb128> thx for responding/helping us to get those MIRs sorted out!
[14:57] <hellsworth> ok made them fix committed. thanks for the advice, yall
[14:57] <cpaelzer> only because I try to get under Laneys couch to scare him
[14:57] <seb128> and it looks like we have no other topic for the meeting, so let's wrap now
[14:57] <seb128> thanks everyone!
[14:57] <hellsworth> thanks!
[14:58] <oSoMoN> thanks
[14:58] <seb128> #endmeeting
[14:58] <meetingology> Meeting ended Tue Jan  7 14:58:21 2020 UTC.
[14:58] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2020/ubuntu-desktop.2020-01-07-14.30.moin.txt
[14:58] <oSoMoN> hellsworth, https://launchpad.net/~ubuntu-archive/+members for a list of archive admins
[14:59] <hellsworth> Ah thanks for that useful tidbit oSoMoN
[15:00] <Laney> Trevinho: could you prep the stuff for gnome-shell/eoan pls?
[15:00] <Trevinho> Laney: ok
[15:00] <Laney> and weren't there some mutter bugs that needed updating?
[15:01] <Laney> thanks 😘😘😘😘😘
[15:01] <Trevinho> mh, need to look, but i think they should be all set
[15:01] <Trevinho> iiiirc
[17:43] <Laney> woohoo first systemd commit https://github.com/systemd/systemd/commit/625077264ba01a108386eeea733ee244e6b7ff14
[17:48] <hellsworth> nice Laney ! that's something to be proud of for sure :)
[17:59] <Laney> :>
[17:59] <Laney> night homies
[18:00] <hellsworth> cheers!