16:02:59 <adamw> #startmeeting F31-blocker-review
16:02:59 <zodbot> Meeting started Mon Oct  7 16:02:59 2019 UTC.
16:02:59 <zodbot> This meeting is logged and archived in a public location.
16:02:59 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:59 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:02:59 <adamw> #meetingname F31-blocker-review
16:02:59 <adamw> #topic Roll Call
16:02:59 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:03:04 <adamw> once more, with feeling!
16:03:08 <frantisekz> .hello2
16:03:09 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:03:10 <kalev> .hello2
16:03:12 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:03:13 <kparal> I'm here just for an hour or so
16:03:13 <tablepc> .hello2
16:03:15 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
16:03:27 <coremodule> .hello2
16:03:28 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:03:34 <coremodule> Good morning/evening all!
16:03:40 * coremodule ready to secretarialize!
16:03:45 <coremodule> there!
16:04:23 <adamw> thank you mr. secretaray
16:04:25 <adamw> ...ry
16:05:58 <tablepc> Are we almost threre now!?
16:06:11 <adamw> we are now cmurf is here
16:06:22 <cmurf> we are now what that i am here
16:06:31 <cmurf> .hello chrismurphy
16:06:32 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:06:37 <coremodule> the name's ray, secretaray
16:07:02 <adamw> is everyone done making fun of my superfluous As now?
16:07:23 <adamw> alrighty, impending boilerplate then
16:07:33 <adamw> #chair coremodule kparal
16:07:33 <zodbot> Current chairs: adamw coremodule kparal
16:07:38 <adamw> #topic Introduction
16:07:38 <adamw> Why are we here?
16:07:39 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:07:39 <adamw> #info We'll be following the process outlined at:
16:07:39 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:40 <adamw> #info The bugs up for review today are available at:
16:07:42 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:46 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:48 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:50 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:07:52 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:07:54 <adamw> #info For F31 Final, we have:
16:07:56 <adamw> #info 5 Proposed Blockers
16:07:58 <adamw> #info 7 Accepted Blockers
16:08:00 <adamw> #info 2 Proposed Freeze Exceptions
16:08:02 <adamw> #info 4 Accepted Freeze Exceptions
16:08:04 <adamw> #info coremodule will secretarialize
16:08:12 <adamw> #info without further ado, let's start in with proposed Final blockers
16:08:19 <adamw> #topic (1757948) fwupd.service fails to start if /var/cache/fwupd doesn't exist (e.g. clean install)
16:08:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1757948
16:08:20 <adamw> #info Proposed Blocker, fwupd, ASSIGNED
16:08:33 <adamw> this is pretty open and shut, it breaks software update on Workstation.
16:08:39 <kalev> +1 blocker
16:08:40 <coremodule> aye, +1 blocker
16:09:26 <frantisekz> +1 blocker for sure
16:09:44 <kparal> how exactly is gnome-software broken when fwupd.service doesn't run?
16:09:56 <adamw> it just refuses to do the update with an error about fwupd
16:10:11 <tablepc> It times out when trying to lo0ad updates
16:10:21 <kparal> what a fault-tolerant software
16:10:21 <adamw> https://openqa.fedoraproject.org/tests/464372#step/desktop_update_graphical/30
16:10:27 <kparal> +1 blocker
16:11:16 <adamw> proposed #agreed 1757948 - AcceptedBlocker (Final) - this is a clear violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated"
16:11:35 <frantisekz> ack
16:11:40 <coremodule> ack
16:11:53 <kalev> hm, but gnome-software isn't a console tool
16:12:01 <kalev> isn't there a criteria for graphical tool?
16:12:18 <frantisekz> hmm, good catch kalev
16:12:20 <tablepc> yes
16:12:25 <adamw> oh sorry
16:12:29 <adamw> i indeed pasted the wrong criterion
16:12:32 <kparal> the only one who read the justification :)
16:12:38 <kparal> kalev++
16:12:38 <zodbot> kparal: Karma for kalev changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:13:00 <frantisekz> anyway, we can block on criterion about failed services in default installation too
16:13:03 <adamw> proposed #agreed 1757948 - AcceptedBlocker (Final) - this is a clear violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)."
16:13:09 <kalev> ack
16:13:10 <adamw> that was a little test to see who was paying attention :P
16:13:12 <frantisekz> ack
16:13:15 <cmurf> ack
16:13:17 <adamw> frantisekz: oddly it doesn't fail that test
16:13:26 <frantisekz> huh
16:13:26 <adamw> i think fwupd might be started on demand when you run gnome-software, not just started on boot
16:13:32 <adamw> (or possibly it just doesn't fail in time, i dunno)
16:13:37 <kalev> yeah, I think that's the case
16:13:44 <kalev> (on-demand)
16:13:48 <adamw> that'd explain it
16:13:59 <adamw> #agreed 1757948 - AcceptedBlocker (Final) - this is a clear violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)."
16:14:06 <adamw> #topic (1755898) numlock handling is seriously broken
16:14:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1755898
16:14:06 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:14:16 <adamw> so, this is one of the ones i asked kalev to step in for (thanks kalev!)
16:14:18 <tablepc> the gnome software fails showing a fwupd timeout
16:14:41 <adamw> this came up last week and several people were in favor of blocking on broken modifier keys in principle, but we don't currently have a criterion that covers it
16:14:47 <adamw> so bcotton proposed one on test@ last week:
16:14:56 <adamw> "For all release-blocking desktops, the Caps Lock and Num Lock keys
16:14:56 <adamw> must correctly toggle the relevant behavior for the desktop and all
16:14:56 <adamw> applications. The behavior must be consistent with the displayed
16:14:56 <adamw> status on physical or virtual keyboards, where applicable."
16:14:59 <adamw> what do you think of that?
16:15:25 <kalev> I think it makes sense to take this as a blocker, but I have no insight what the fix would involve, that's up to gnome-shell people :)
16:15:35 <kalev> as for me personally, the blocker part is that gnome-shell and apps are inverted
16:15:44 <coremodule> I think that is an appropriate criteria, if we accept it as a blocker, would it be for that new criteria?
16:16:03 <cmurf> i don't think a new criterion is required, I think it's basic functionality
16:16:11 <adamw> coremodule: i'd say the choice we have on the table is to agree to adopt the new criterion and accept the bug as blocking it
16:16:17 <cmurf> but i'm not opposed to carving out definitions for basic functionality
16:16:59 <coremodule> adamw, Alright, can we accept the criteria and accept this bug as a blocker in this meeting? Or do we need a larger forum (list) to do that?
16:17:46 <coremodule> cmurf, do you mean accept this bug on the "basic functionality" criteria, but somewhere list what we consider "basic functionality" and point the "basic functionality" to that list?
16:17:50 <adamw> it's already been on the list with no objections
16:17:54 <kparal> mclasen just updated the bug report, seems to indicate he doesn't believe we should block on numlock behavior
16:17:56 <coremodule> or you are okay with the new bug?
16:17:56 <cmurf> coremodule: if you want
16:18:02 <adamw> so we could agree it in the meeting i'd say
16:18:10 <coremodule> adamw, yeah, I know, I'm just wondering where we can agree to make it official
16:18:12 <coremodule> gotcha
16:18:16 <mclasen> the last time I looked at numlock (which was long ago), the X server couldn't find out if it is actually on or not
16:18:24 <kalev> I think there's two parts to the numlock issue
16:18:40 <kalev> issue one is that numlock light is not reflecting the reality
16:18:45 <kalev> this one I don't think should be a blocker
16:18:54 <kparal> I had no numlock issues in the next several years, everything worked reliably
16:19:00 <kalev> issue two is that gnome-shell and apps get the numlock state differently
16:19:09 <cmurf> if numlock really isn't expected to work, then we need to define "basic functionality" because numlock is basic functionality linguistically, from a broad user point of view since the 1980's
16:19:13 <kalev> so that in shell you get numbers, in firefox you get arrows, or vice versa
16:19:16 <kparal> *past several years :)
16:19:24 <kalev> I think issue two should be a blocker, but the numlock light issue should not be
16:20:04 <mkolman> kalev: ouch, such a missmatch sounds pretty critical to me (and indeed, light being on or off is not that big issue)
16:20:14 * kalev nods.
16:21:26 <kparal> that's going to be much harder to define, though
16:21:31 <kparal> as a criterion
16:21:52 <kparal> I'd prefer requiring numlock to work well overall
16:22:36 <kparal> of course if we want to block just on mismatch between apps and shell, we can say it's a problem in the "main panel" and use the existing criteria for it
16:23:00 <adamw> getting the light state right in all cases can be pretty tricky, iirc
16:23:28 <kparal> let's define it as "kparal's keyboard" then
16:23:43 <adamw> since the firmware can touch it and the os can't actually query its state, or something like that
16:24:10 * kalev agrees.
16:24:31 <adamw> (on my model M all three modifier lights seem to be on all the time, heh)
16:24:35 <kparal> so we say it has to work well, but the light switch doesn't need to reflect the state correctly? :)
16:24:59 <adamw> i mean, it sounds weird, but that seems to be where we are?
16:25:12 <adamw> you should be able to toggle it and it should work consistently
16:25:21 <kparal> it's funny but I don't mind it too much
16:26:07 <kparal> adamw: want to try to phrase that?
16:26:15 <adamw> not...right now?
16:26:21 <adamw> let's see
16:26:25 * kparal shrugs
16:26:31 <kparal> I thought we'd vote on it right now
16:26:37 <coremodule> adamw, are your model M's PS2 or the 5 pin DIN connector? (just for reference, and cause I'm interested)
16:26:40 <tablepc> I think it's the sort of problem end users and pundits will complain about
16:27:22 <adamw> proposed #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted
16:27:40 <adamw> coremodule: ps/2 through a usb adapter
16:27:45 <kparal> ack
16:27:48 <coremodule> ack
16:28:08 <frantisekz> ack
16:28:16 <kalev> ack
16:28:16 <adamw> kalev, ok with you?
16:28:19 <kalev> yep
16:28:19 <adamw> cool
16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted
16:28:48 <adamw> #topic (1758873) Regression: X selection buffers are not available to Qt applications
16:28:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1758873
16:28:48 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:29:45 <frantisekz> hmm, is there any criterion we can use this for?
16:29:52 <kparal> I'm not that concerned about primary/secondary selection as for the clipboard one
16:29:56 <adamw> not unless any qt apps are default
16:30:08 <kparal> I don't think we need to have qt apps by default
16:30:23 <frantisekz> nope
16:30:25 <kparal> it's a failure of the actual system, not in the apps
16:30:36 <frantisekz> (the only blocking qt app is fedora media writer)
16:30:48 <kparal> this is not about a particular app working properly, but about shell working well
16:31:07 <adamw> the failure is *experienced* in apps though
16:31:15 <frantisekz> shell works just fine, apps don't
16:31:17 <kparal> as is numlock
16:31:18 <adamw> and we apparently don't have any apps installed by default where you're going to encounter it?
16:31:35 <frantisekz> no, so, we can't do more than fe here
16:31:42 <kparal> you'll encounter right after installing vlc or similar
16:31:55 <frantisekz> yeah
16:32:01 <frantisekz> vlc isn't even in Fedora repos
16:32:09 <adamw> i'd be curious to know if the fix for kparal's other pasting bug fixes this one too...
16:32:14 <kparal> frantisekz: stop being an ass
16:32:18 <adamw> =)
16:32:56 <kparal> adamw: I'd say this is not related, my clipboard fix is in spice, that shouldn't be involved here
16:33:23 <adamw> oh yeah hum
16:33:38 <adamw> i misremembered that it had changes in non-spice bits too, but it doesn't
16:34:36 <kparal> I think we should test this a bit more first. If really no QT app can accept any clipboard input, that's a problem as hell
16:34:51 <kparal> and in that case I disagree that it's not a blocker
16:35:10 <kparal> I'd be happy to draft a new criterion for clipboard, if you so desire
16:35:18 <kalev> soooo ... punt for more testing?
16:35:19 <kparal> but first we should verify this
16:35:25 <cmurf> i agree with kparal
16:35:36 <adamw> i'm ok with that
16:36:05 <adamw> "This is an issue for applications still using the X buffers"
16:36:26 <adamw> implies it's not an issue for apps which *don't* use the X buffers. i am not sufficiently au fait with paste mechanics to know the implications of that though.
16:36:41 <kparal> me neither
16:37:17 <kparal> even if I knew what your funny words meant
16:37:37 <kparal> punt and test, then?
16:37:42 <adamw> yeah
16:38:15 <adamw> test both selection-based and ctrl-c/ctrl-v based copying too...i guess that may be important
16:38:32 <kparal> will do
16:39:02 <adamw> proposed #agreed 1758873 - punt (delay decision) - this does not clearly come under any existing criteria, but we may be open to considering a new one; however, we want to do more testing to identify the exact extent of the problem first
16:39:15 <coremodule> ack
16:39:18 <kparal> ack
16:39:41 <frantisekz> ack
16:39:45 <adamw> #agreed 1758873 - punt (delay decision) - this does not clearly come under any existing criteria, but we may be open to considering a new one; however, we want to do more testing to identify the exact extent of the problem first
16:39:54 <adamw> #topic (1759215) Alt-tab for siwtching-windows does not work
16:39:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1759215
16:39:54 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:39:59 * adamw hits alt-tab
16:40:02 <adamw> it works!
16:40:06 <adamw> rejected
16:40:08 <adamw> next bug
16:40:09 <adamw> :P
16:40:12 <kparal> closed worksforme
16:40:28 <adamw> oh
16:40:36 <adamw> this is about setting it to do something different from what it does by default
16:41:22 <kalev> I don't think this should be a blocker. The default configuration is what needs to work, but not tweaks like that.
16:41:26 <adamw> if that configuration is broken it's a bug, doesn't seem like a blocker though.
16:41:30 <adamw> right
16:42:10 <kparal> however, it might also mean that gnome-control-center doesn't work correctly
16:42:16 <kparal> if pingou tried to set it through it
16:42:31 <kparal> that's the second link he provided
16:42:41 <mkolman> is there some major overhaul going on with input and clipboard handling ? all these issues seem kinda related
16:42:42 <kparal> so it seems he tried
16:42:56 <kparal> mkolman: mutter now has a clipboard manager
16:43:01 <kparal> I don't know about any other changes
16:43:18 <mkolman> hmm, maybe that, weird
16:44:01 <adamw> it's the clipboard manager
16:44:05 <adamw> it throws off a lot of other stuff
16:44:16 <adamw> but this doesn't have anything to do with that, i don't think
16:44:16 <kparal> adamw: can you try to set Switch windows in g-c-c to Alt-Tab?
16:44:23 <adamw> anything paste-y is down to the clipboard manager though.
16:44:59 <kparal> as in the video here: https://blogs.gnome.org/fmuellner/2018/10/11/the-future-of-alternatetab-and-why-you-need-not-worry/
16:45:03 <adamw> kparal: just tried it, works fine for me.
16:45:08 <kparal> ok
16:45:11 <adamw> on my desktop not a clean install, though.
16:45:57 <kparal> so we need to debug this further but at least for some people it seems to work
16:46:15 <kparal> I could see this accepted if shortcut assignments were broken
16:46:22 <adamw> if it was just this one, i'd still be -1
16:46:36 <adamw> if all shortcut assignment in gcc was broken maybe +1, but we're way off in theoretical land at that point
16:46:38 <adamw> so, i'm -1 for now
16:46:54 <kparal> but on the grounds of changing alt+tab behavior to be per-window, I'm -1
16:46:57 <adamw> we can of course re-propose if it turns out to be worse than we thought
16:47:03 <kalev> I'm -1 as well for now
16:47:08 <cmurf> i'm a 0 until i better understand if it's just a cosmetic bug or really a basic functionality bug
16:47:15 <frantisekz> -1 too from me
16:47:27 <cmurf> punt needinfo
16:48:01 <kparal> either works for me
16:48:37 <adamw> well, that's -4 +0 so let's reject for now
16:49:47 <adamw> proposed #agreed 1759215 - RejectedBlocker (Final) - so far, the bug as we understand it does not really violate the criteria or appear serious enough to block the release, and may not even be reproducible. It can be re-proposed if more information emerges that makes it seem more serious
16:50:20 <kalev> ack
16:50:30 <frantisekz> ack
16:50:54 <kparal> ack
16:51:05 <coremodule> ack
16:52:20 <adamw> #agreed 1759215 - RejectedBlocker (Final) - so far, the bug as we understand it does not really violate the criteria or appear serious enough to block the release, and may not even be reproducible. It can be re-proposed if more information emerges that makes it seem more serious
16:52:26 <adamw> #topic (1703700) Newer kernels do not boot and have invalid grub.cfg entries (on Xen DomU guests)
16:52:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1703700
16:52:26 <adamw> #info Proposed Blocker, grub2, NEW
16:52:35 <adamw> so, this one is interesting
16:52:45 <coremodule> ah crap, I forgot to test this...
16:53:16 <cmurf> it is interesting and I've never used xen
16:53:21 <kalev> I remember using Xen with RHEL 5 :) that was a long time ago!
16:53:29 <cmurf> the pygrub bit is interesting too - where is that?
16:53:38 <cmurf> is pygrub called from the Dom0 or DomU?
16:54:04 * pwhalen slips in the backdoor
16:54:43 <adamw> well, i meant it was interesting in that it kinda gives us a decision point for the xen criterion
16:54:57 <adamw> do we stick with it for f31 and accept this as a blocker, or say we're going with the 'cloud only' rewrite of the criterion and reject it
16:55:12 <adamw> (and in fact...has anyone tried deploying to a xen-y ec2 instance and updating the kernel?)
16:55:45 <adamw> hmm, that's pretty much where we were last week
16:55:59 <adamw> "punt (delay decision) - the details of the issue here are not yet entirely clear so it's hard to decide if it's a blocker, also we're not sure yet if we intend to complete the criterion change to block only on ec2 rather than all xen guest functionality"
16:56:04 <adamw> and coremodule said he'd test it but didn't :P
16:56:07 <adamw> .fire coremodule
16:56:07 <zodbot> adamw fires coremodule
16:56:11 <coremodule> Dammit
16:56:16 <coremodule> I can do that right now...
16:56:25 <coremodule> Just give me a few minutes
16:56:43 <cmurf> so on the test@ list this came up for discussion and the xen folks popped in and it was discussed
16:57:19 <cmurf> so i'm wondering if we should ping them for help on how it should work going forward
16:57:19 <adamw> not since last week, though.,
16:57:34 <adamw> and they still frankly haven't convinced me we have a good reason to keep the criterion.
16:57:39 <cmurf> either always stomp on grub.cfg with a grub2-mkconfig every time a kernel is installed
16:57:43 <cmurf> or support BLS
16:57:50 <adamw> that's just, like, my opinion, though, man.
16:57:55 <cmurf> adamw: I agree with that but here's another example case
16:58:01 <cmurf> ask them for help to fix this
16:58:13 <cmurf> if they can't do that, it's a well... here's why this is hard to keep xen as a blocker
16:58:56 <cmurf> we can't block indefinitely someone has to fix stuff, if it isn't going to get fixed, then the blocker criterion needs to be removed
16:58:59 <cmurf> same as everything else
16:59:11 <pwhalen> sounds reasonable
16:59:33 * kparal needs to go. bye everyone
16:59:40 <kalev> bye kparal
16:59:40 <cmurf> kparal: cya
16:59:44 <adamw> this very bug was in fact brought up in the xen criteria thread in may
16:59:52 <cmurf> ohreally
16:59:54 <adamw> i don't see a sudden influx of xen folks eager to help us fix it, does anyone else?
16:59:54 <cmurf> oops
17:00:05 * coremodule looks
17:00:24 * coremodule can’t see far, the xun is in his eyes
17:00:30 <cmurf> proposal: punt one more time, bring up this bug and the test@ discussion on devel@
17:00:55 <cmurf> and if there's no actual fix in progress by next week, then nix the xen criterion
17:01:39 <coremodule> I can get behind that
17:01:40 <adamw> i'm just finding the post link for posterity
17:01:40 <pwhalen> +1 proposal
17:01:57 <frantisekz> cmurf +1
17:02:01 <coremodule> I can test a little more thoroughly that way
17:02:08 <coremodule> +1 cmurf proposal
17:02:55 <adamw> hyperkitty is not great at this, sigh
17:03:43 <cmurf> coremodule: can you post to devel@ ?
17:04:08 <coremodule> cmurf, yes, is there already a thread i can continue or should I start a new one on @devel?
17:04:16 <cmurf> bug + post adamw is referring to + the larger xen test@ thread?
17:04:30 <cmurf> new one on devel@ so it gets full exposure
17:04:50 <adamw> it's the "Criteria / validation proposal: drop Xen" thread that went to test@ and a bunch of xen lists/people
17:04:54 <cmurf> and in subject I'd include removal of xen release criterion
17:05:10 <coremodule> gotcha
17:05:12 <coremodule> wilco
17:05:54 <adamw> welp, i can't find an archive link at all, i'll paste the quote into the bug for the record
17:05:54 <cmurf> basically you wanna troll the xen folks right? if your bait doesn't catch a fish, then there just isn't any interest in keeping it as a blocking feature
17:05:59 <adamw> but +1 cmurf proposal again
17:06:41 <adamw> proposed #agreed 1703700 - punt (delay decision) again - we meant to re-test this from scratch last week, but didn't manage to. we will pull the xen folks in on the bug this week and see if any progress can be made before finally deciding what to do next week
17:07:02 <coremodule> lol
17:07:03 <pwhalen> ack
17:07:16 <coremodule> i like the "*we* meant to test this"
17:07:17 <cmurf> ack
17:07:17 <coremodule> ack
17:07:30 <kalev> ack
17:07:50 <frantisekz> ack
17:09:22 <adamw> #agreed 1703700 - punt (delay decision) again - we meant to re-test this from scratch last week, but didn't manage to. we will pull the xen folks in on the bug this week and see if any progress can be made before finally deciding what to do next week
17:09:42 <adamw> coremodule: corporate responsibility means no-one has to take the fall!
17:10:00 <coremodule> yay!
17:10:03 <adamw> #topic Proposed freeze exceptions
17:10:07 <adamw> #info let's move onto the proposed FEs
17:10:14 <adamw> #topic (1759186) Include GNOME 3.34.1 in Fedora 31 Final
17:10:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1759186
17:10:14 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
17:10:23 <adamw> as this is a bugfix release, i'm OK with it early in freeze, so +1
17:10:45 <frantisekz> +1
17:11:08 <coremodule> +1
17:11:29 <pwhalen> +1
17:13:01 * kalev abstains from voting due to conflict of interest.
17:13:11 <adamw> proposed #agreed 1759186 - AcceptedFreezeException (Final) - we agree it makes sense to pull this in early in freeze as it is a bug fix release and addresses many bugs that were encountered and reported in Fedora 31 Beta testing
17:13:11 <cmurf> adamw there is a late blocker proposal
17:13:15 <frantisekz> ack
17:13:17 <adamw> cmurf: ok, i'll come back to that
17:13:22 <kalev> ack
17:15:11 <adamw> one more ack?
17:15:25 <pwhalen> ack
17:16:12 <adamw> #agreed 1759186 - AcceptedFreezeException (Final) - we agree it makes sense to pull this in early in freeze as it is a bug fix release and addresses many bugs that were encountered and reported in Fedora 31 Beta testing
17:16:18 <adamw> #topic (1746413) selinux blocks dbus-broker from starting
17:16:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1746413
17:16:19 <adamw> #info Proposed Freeze Exceptions, selinux-policy-targeted, POST
17:16:26 <adamw> note, this is FE not blocker as it's specific to a non-blocking arch
17:16:33 <adamw> but obvious +1 for me, we should fix our non-blocking arches!
17:16:38 <frantisekz> +1
17:17:18 <kalev> +1 FE
17:18:05 <adamw> proposed #agreed 1746413 - AcceptedFreezeException (Final) - this is accepted as an FE as a showstopping issue on a non-blocking arch that cannot be fixed with an update alone
17:18:17 <frantisekz> ack
17:18:19 <kalev> ack
17:19:09 <coremodule> ack
17:19:17 <pwhalen> +1/ack
17:20:00 <adamw> #agreed 1746413 - AcceptedFreezeException (Final) - this is accepted as an FE as a showstopping issue on a non-blocking arch that cannot be fixed with an update alone
17:20:24 <adamw> #topic Proposed Final blockers, redux
17:20:31 <adamw> #info we have a new proposed Final blocker, so let's cover that now
17:20:32 <adamw> #topic (1759221) after changing Formats to Germany then back to English, localectl shows Germany even after a reboot
17:20:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1759221
17:20:32 <adamw> #info Proposed Blocker, gnome-control-center, NEW
17:20:53 <cmurf> OK so this is not a Germany/German specifci bug, that's just what I happened to use
17:21:00 <cmurf> others have reproduced it
17:21:14 <cmurf> fix is proposed and works
17:21:43 <cmurf> might be a candidate of fastest fixed blocker bugs if it's accepted as a blocker
17:24:00 <adamw> yeah, i can go +1 for that i think
17:24:12 <frantisekz> okay, +1
17:24:13 <cmurf> looks like it'll either beat freeze or get rolled into GNOME 3.34.1 update
17:24:17 <adamw> i'd count it as basic functionality of the panel applet that's meant to change...exactly that :)
17:25:15 <adamw> mcatanzaro voted +1 in bug
17:25:17 <adamw> so that's +3
17:25:31 <cmurf> mclasen was -1 on workstation channel
17:25:48 <adamw> proposed #agreed 1759221 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" (this counts as 'basic functionality' of the Language and Formats applet)
17:25:57 <frantisekz> workstation channel doesn't count
17:26:01 <frantisekz> :D
17:26:04 <adamw> too many damn channels
17:26:12 <adamw> kalev, want to break the workstation team tie? :)
17:26:21 <cmurf> haha
17:26:35 <kalev> +1 :)
17:26:45 <cmurf> well i'm on the workstation wg too so it was tecnically 2 to 1
17:26:48 <adamw> ok, so +4 / -1, proposal stands
17:26:49 <cmurf> and now 3 to 1
17:28:01 <kalev> looks like we are getting a numlock fix, by the way: https://gitlab.gnome.org/GNOME/mutter/merge_requests/834
17:28:26 <kalev> mutter 3.34.1 is due later today so it should get fixed in 3.34.1 megaupdate
17:29:44 <adamw> yay
17:29:50 <adamw> ack/nack/patch?
17:29:59 <kalev> ack
17:30:51 <frantisekz> ack
17:31:18 <adamw> #agreed 1759221 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" (this counts as 'basic functionality' of the Language and Formats applet)
17:31:20 <cmurf> ack
17:31:28 <mclasen> adamw: I don't think the workstation team has a vote in this ?!
17:31:59 <adamw> eh, formally you'd all count as having individual votes as 'developers' i guess
17:32:14 <adamw> but as has been mentioned before the voting system here is a highly advanced heuristic that lives in my head :P
17:33:11 <adamw> #topic Accepted Final blockers
17:33:40 <adamw> #info there has been some movement on 1747408 at least, which is good
17:34:18 <kalev> I'm not sure I agree with the direction the bug is heading though. Looks like the fix is to print out a message in dnf and leave gnome-software distro upgrades out in the cold
17:34:22 <adamw> #info and also a bit on 1728240
17:34:34 <adamw> kalev: yeah, it doesn't seem entirely sufficient at present
17:34:48 <adamw> i'm gonna wait a bit and see what more they come up with, but i agree we need to cover the gnome-software path
17:34:56 <kalev> great :)
17:35:15 <adamw> #info aside from that, we're mostly waiting on devs to fix each bug
17:35:32 <adamw> kalev: i guess we can trust you guys to be on top of the gnome-y accepted ones?
17:35:59 <cmurf> our docs say Gnome-Software is the recommended way to do a major version upgrade for Workstation
17:36:06 <cmurf> so that really does have to work
17:36:45 <adamw> yeah
17:37:03 <kalev> adamw: I'll defer to mclasen for engineering resources :)
17:37:24 * mclasen is not following and has no resources to offer
17:37:58 <kalev> mclasen: adamw just wanted assurance that we're on top of the accepted blockers, https://qa.fedoraproject.org/blockerbugs/milestone/31/final/buglist
17:38:06 <kalev> mclasen: mostly shell bugs it seems
17:40:04 <adamw> i do see progress happening upstream on each of them
17:40:07 <adamw> so i'm not too worried
17:40:22 <adamw> #info progress is happening upstream on all the GNOME blockers
17:40:45 <mclasen> florian is just back today
17:41:21 <adamw> #topic Open floor
17:41:29 <adamw> I think that's everything, so thanks for coming and voting, folks
17:41:33 <adamw> anyone have any other F31-ish business?
17:41:46 <pwhalen> one
17:41:48 <cmurf> free is tomorrow
17:41:52 <cmurf> or tonight
17:41:59 <cmurf> depending on your location :D
17:42:11 <pwhalen> I proposed this as we discussed last week - https://bugzilla.redhat.com/show_bug.cgi?id=1750575
17:42:12 <cmurf> s/free/freeze
17:42:21 <kalev> I'll have an appstream-data update/blocker coming up once we have the 3.34.1 megaupdate pushed stable
17:42:27 <pwhalen> for some reason didnt show up (dnfdragora bug)
17:42:50 <pwhalen> now moved to libdnf
17:43:28 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1759193 (gnome-software regression after appstream-glib update) looks blockerish
17:43:58 <adamw> pwhalen: oh, it didn't show because it has a RejectedBlocker tag
17:44:08 <adamw> from Beta discussion
17:44:12 <adamw> you need to clear that for it to show up again
17:44:20 <adamw> #topic proposed Final blocker redux redux
17:44:30 <adamw> #info there is one more bug supposed to be proposed as a blocker which was not showing up
17:44:31 <pwhalen> ah
17:44:34 <cmurf> yeah i'm a weak +1 maybe on that - the crash bothers me even if it doesn't seem to break anything
17:44:44 <cmurf> that = 1750575
17:44:51 <pwhalen> agreed, just looks bad
17:44:59 <cmurf> what product?
17:45:06 <adamw> just let me get the topic in here
17:45:21 <adamw> #topic (1750575) dnfdragora complains that dnf is locked by another process after updates
17:45:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750575
17:45:42 <adamw> #info Proposed Blockers, libdnf, NEW
17:45:45 <adamw> ok, there we go.
17:45:56 <adamw> i'm really on the fence with this one
17:45:58 <cmurf> i'm not actually certain the update took if there's a dnf related crash
17:46:08 <pwhalen> I'm a weak +1 as well, works but doesnt look good for a final.
17:46:09 <cmurf> but then also i wonder if rpm database is up to date or corrupt
17:46:13 <adamw> per the beta discussion we checked that, it did work.
17:46:26 <adamw> pwhalen said "The updates are applied successfully, but this message is confusing."
17:46:41 <cmurf> yeah it's icky
17:46:44 <cmurf> this is what product?
17:46:57 <cmurf> but i'm not quite sure it's a blocker
17:47:16 <adamw> cmurf: the blocking thing it affects is Xfce
17:47:20 <cmurf> gotcha
17:47:21 <adamw> which is blocking on ARM
17:47:24 <cmurf> yeah
17:47:42 <cmurf> Common Bugs?
17:47:52 <pwhalen> but it affects most desktop spins on all arches
17:48:16 <cmurf> here's the thing - is is vaguely possible the user gets a different libdnf crash that *is* a problem and isn't this bug?
17:48:38 <cmurf> suddenly it makes libdnf crashes ambiguous whether it's the common bugs bug or some other bug
17:48:59 <cmurf> if the crash call trace is distinctive enough then it might be OK to say this can be fixed with an update
17:49:17 <cmurf> and just expect people to know this is an issue from Common Bugs
17:49:36 <cmurf> pwhalen: hmm that's bad too that it's not a one off
17:50:02 <cmurf> but on the plus side, lots of people will know about it when someone asks, who hasn't yet read Common Bugs :P
17:50:53 <cmurf> interesting question, has the update succeeded if the user can't tell it has succeeded?
17:52:08 <adamw> yes. yes it has
17:52:14 <adamw> the user is not always right. :P
17:52:18 <pwhalen> heh
17:53:39 <adamw> so, i dunno. this is really borderline
17:55:38 <cmurf> i agree it's borderline
17:56:33 <adamw> i kinda suspect it would not pass the Last Blocker Test
17:56:40 <adamw> but...otoh, if GNOME Software did this, what would we vote
17:56:53 <adamw> i think i'm a weak +1
17:56:54 <cmurf> depends on the error
17:56:56 <pwhalen> of course we would block
17:57:02 <cmurf> but yeah i think good chance we block
17:57:15 <cmurf> part of that is GUI programs do have a higher burden of user advocacy :D
17:59:25 <adamw> so we have weak +2 so far
18:01:09 <adamw> cmurf, do you have a vote?
18:01:38 * satellit_ seems need to wait for dragora-updater before dragora will work...same issue?
18:02:16 <cmurf> not really
18:02:18 <adamw> dunno
18:02:31 <cmurf> seriously on the fence
18:02:40 <cmurf> I think Common Bugs is weakly adequate
18:03:17 <adamw> i guess let's punt and ask for votes in-bug? seems we don't have a clear vote here
18:03:28 <cmurf> ok
18:03:46 <adamw> proposed #agreed 1750575 - punt (delay decision) - we did not have enough votes for a clear decision on this in meeting; we will ask for votes in-bug to get a clearer decision
18:04:13 <cmurf> this is a case for the power of persuasive writing :)
18:04:54 <adamw> #topic Open floor
18:05:03 <adamw> ok, so once more, i think we're done :) thanks again everyone
18:05:05 <adamw> oh doh
18:05:16 <adamw> #undo
18:05:16 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f93f098b110>
18:05:36 <adamw> #topic (1750575) dnfdragora complains that dnf is locked by another process after updates
18:05:41 <adamw> #agreed 1750575 - punt (delay decision) - we did not have enough votes for a clear decision on this in meeting; we will ask for votes in-bug to get a clearer decision
18:05:45 <adamw> #topic Open floor
18:05:51 <adamw> please god let this nightmare end now
18:06:35 <cmurf> yeah i say that every day but not ever about Fedora!
18:06:57 <adamw> =)
18:07:45 <adamw> thanks once more, everyone
18:07:46 <adamw> #endmeeting