17:01:59 <adamw> #startmeeting F36-blocker-review
17:01:59 <zodbot> Meeting started Mon Feb 14 17:01:59 2022 UTC.
17:01:59 <zodbot> This meeting is logged and archived in a public location.
17:01:59 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:01:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:59 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:02:03 <adamw> #meetingname F36-blocker-review
17:02:03 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:02:06 <adamw> #topic Roll Call
17:02:29 <nielsenb> here
17:02:39 <adamw> who's around for blocker review fun?
17:03:28 <lruzicka> .hello2
17:03:29 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:03:43 <bcotton> .hello2
17:03:44 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:06:47 <coremodule> .hello2
17:06:48 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:08:41 <adamw> #chair coremodule bcotton
17:08:41 <zodbot> Current chairs: adamw bcotton coremodule
17:10:37 <adamw> boilerplate alert
17:10:38 <adamw> #topic Introduction
17:10:42 <adamw> Why are we here?
17:10:45 <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.
17:10:48 <adamw> #info We'll be following the process outlined at:
17:10:52 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:10:56 <adamw> #info The bugs up for review today are available at:
17:10:59 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:11:02 <adamw> #info The criteria for release blocking bugs can be found at:
17:11:05 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:11:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
17:11:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
17:11:21 <adamw> #info for Beta, we have:
17:11:27 <adamw> #info 2 Proposed Blockers
17:11:31 <adamw> #info 6 Accepted Blockers
17:11:33 <adamw> #info 1 Accepted Freeze Exceptions
17:11:41 <adamw> #info for Final, we have:
17:11:44 <adamw> #info 6 Proposed Blockers
17:11:47 <adamw> #info 2 Accepted Blockers
17:11:55 <adamw> who wants to secretarialize?
17:12:10 <coremodule> what a question
17:12:11 <coremodule> I'll do it
17:12:34 <lruzicka> cool, thanks
17:13:31 <adamw> hehe
17:13:36 <adamw> #info coremodule will secretarialize
17:13:58 <adamw> ok, let's get rolling with:
17:14:02 <adamw> #topic Proposed Beta blockers
17:14:09 <adamw> #topic (2032085) Some variants are missing /etc/resolv.conf symlink (use systemd-resolved)
17:14:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2032085
17:14:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/581
17:14:18 <adamw> #info Proposed Blocker, distribution, POST
17:14:21 <adamw> #info Ticket vote: BetaBlocker (+1,0,-3) (+sgallagh, -imsedgar, -nielsenb, -bcotton)
17:14:25 <adamw> so last week we decided to defer this to fesco
17:14:46 <adamw> but i noticed friday we'd forgotten to actually do that :D so I did: https://pagure.io/fesco/issue/2760
17:14:54 <adamw> so we should probably just punt this one and wait on fesco.
17:15:01 <lruzicka> sure
17:15:12 <coremodule> sounds good to me
17:15:17 <coremodule> +1 punt for FESCO
17:15:23 <nielsenb> Agreed, though it looks like it might be fixed? So, yay?
17:15:57 <adamw> proposed #agreed 2032085 - as per last week's meeting we don't think this is a blocker under the criteria but believe FESCo should consider it, a ticket has now been filed for FESCo: https://pagure.io/fesco/issue/2760 , so we will wait for them to consider it
17:16:04 <lruzicka> ack
17:16:04 <coremodule> ack
17:16:07 <nielsenb> ack
17:16:16 <adamw> nielsenb: well, that last comment is only for Silverblue, i guess we need to clarify current status for other editions too
17:16:18 <copperi[m]> ack
17:16:18 <bcotton> ack
17:17:17 <adamw> #agreed 2032085 - as per last week's meeting we don't think this is a blocker under the criteria but believe FESCo should consider it, a ticket has now been filed for FESCo: https://pagure.io/fesco/issue/2760 , so we will wait for them to consider it
17:17:23 <adamw> #topic (2033130) exclude_from_weak_autodetect=true effectively renders rich weak dependencies useless
17:17:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2033130
17:17:31 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/602
17:17:34 <adamw> #info Proposed Blocker, dnf, NEW
17:17:36 <adamw> #info Ticket vote: BetaBlocker (+1,0,-0) (+churchyard)
17:19:08 * pwhalen slips in the back
17:19:24 <coremodule> hi pwhalen
17:20:05 <nielsenb> https://bugzilla.redhat.com/show_bug.cgi?id=2042808
17:20:18 <nielsenb> I feel like that dupe gives a good example of a 'broken' thing that used to work
17:21:57 <adamw> man, this feels like a tricky one
17:22:16 <bcotton> so i nominated this based on what i think is a reasonable interpretation of https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update
17:22:21 <adamw> but i think on the whole i'm a weak +1
17:22:46 <nielsenb> It is unclear to me what problem this change is trying to fix?
17:22:49 <adamw> this definitely seems to be affecting several cases where we have a clear design that relies on the existing behaviour, and yeah the langpacks are a good example
17:23:06 <adamw> nielsenb: the idea is that if X recommends Y, and you update X without Y installed, not to install Y
17:23:08 <adamw> (AIUI)
17:23:37 <nielsenb> Okay, but in the process, it breaks if X recommends Y, and you install X, you don't get Y?
17:23:43 <bcotton> given that the change owner here doesn't dispute that the resulting behavior is unintended, it's hard to say "well this is just a design decision that some people don't like"
17:23:54 <adamw> currently if X recommends Y, and you install X then remove Y, when you next update X, dnf will try to pull Y back in
17:24:16 <adamw> nielsenb: not quite that straightforward, the cases it breaks are cases involving 'rich' dependencies
17:24:30 <lruzicka> So when I install X, the Y gets pulled in and I need to remove Y to arrive into this situation?
17:24:34 <bcotton> +1 beta blocker
17:24:42 <lruzicka> And DNF does not complain about me removing Y?
17:24:47 <adamw> yes
17:24:51 <adamw> that's what weak dependecies are for
17:25:29 <lruzicka> And the bug is an RFI ? Or at least it seems to me to be one.
17:25:30 <adamw> X Recommends Y is meant to mean "by default Y will get installed if you install X, but you can remove Y and it's not Against The Rules"
17:25:56 <coremodule> I'm +1 beta blocker
17:25:57 <adamw> lruzicka: no, the bug is *caused* by what's effectively an EFI
17:25:59 <adamw> RFI*
17:26:37 <lruzicka> because I am not getting this behaviour - why not request if X recommends Y, then ask me what to do and if I disapprove, do not install Y.
17:26:49 <adamw> https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect is a Change for F36 to try and solve the "weak dependencies get reinstalled on update even if you specifically removed them before" problem. i.e., that's an RFE. but it turns out to *cause* an unforeseen problem in a more complex (but still fairly common) scenario
17:26:49 <lruzicka> This is what I would think is logical.
17:27:25 <adamw> lruzicka: it's always been a no-no to have that kind of interactivity in fedora package management
17:27:42 <adamw> anyway, we're not spitballing solutions here, just voting on blocker status :D
17:27:50 <pwhalen> +1 beta blocker
17:28:09 <lruzicka> I do not have an idea, so I'll pass unless you need my decision badyl
17:28:11 <lruzicka> badly
17:28:17 <adamw> i guess one thing we could consider is whether it makes more sense as a final blocker
17:28:21 <nielsenb> I agree, I abstain
17:28:27 <adamw> i'm not sure the affected scenarios are critical enough that we should delay the beta if it's not fixed by then
17:28:38 <nielsenb> I don't fully understand the problem, and the ticket doesn't give me any indication of a clear path to a fix
17:28:57 <nielsenb> I feel like it's a blocker of some sort, but not sure where
17:29:02 <adamw> nielsenb: well, the easiest fix is to revert the change and leave things as they are
17:29:45 <nielsenb> But is the 'old' behavior really better than the new broken one? Or are people just more familiar with it?
17:30:08 <adamw> if we were starting from scratch, you might argue that having the "weak dependency gets pulled back in on update" fix is *worth* having the other problem. but we're never starting from scratch, and there should always be a bias towards "leave things as they were" if a change causes something to behave differently in a way that causes problems.
17:30:15 <adamw> nielsenb: see above :D
17:30:29 <nielsenb> Fair enough
17:30:41 <nielsenb> +1 final blocker
17:31:21 <nielsenb> Since 'reverting' is apparently a single line in a config file, delaying blocking that far in seems reasonable
17:31:23 <bcotton> adamw: what final criterion applies better than the basic one I cited?
17:31:56 <adamw> Ben Cotton (he/him): none, but I figure since this is kind of a 'conditional' blocker we can reasonably make the call to apply it in this fashion
17:32:13 <adamw> let me just take a look and see if that's really badly against any rules :D
17:33:54 <bcotton> i won't be heartbroken if we push it to final, but since the solution is likely to be a one-line config change and it violates a basic criterion, i don't see any benefit in us pushing it off and shipping beta with the bad behavior in place
17:34:34 <adamw> okay, it's probably more in line with the rules to take it as beta, i guess
17:34:43 <adamw> we could theoretically waive it to final later on if it became an issue
17:34:46 <adamw> so, let's go with that
17:34:53 <nielsenb> Fine, you twsited my arm
17:34:56 <nielsenb> +1 beta blocker
17:36:21 <adamw> proposed #agreed 2033130 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of Basic criterion "The installed system must be able appropriately to install, remove, and update software...Appropriately means...broadly in line with the user's intent and typical expectations, and the project's intent as to which software should be provided from which repositories etc."
17:36:35 <nielsenb> ack
17:36:37 <coremodule> ack
17:36:40 <lruzicka> ack
17:36:40 <bcotton> ack
17:36:42 <copperi[m]> ack
17:37:37 <adamw> #agreed 2033130 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of Basic criterion "The installed system must be able appropriately to install, remove, and update software...Appropriately means...broadly in line with the user's intent and typical expectations, and the project's intent as to which software should be provided from which repositories etc."
17:38:08 <adamw> ok, there are no proposed Beta FEs, so let's move on to:
17:38:14 <adamw> #topic Proposed Final blockers
17:39:03 <adamw> #topic (2052872) abrt failed to create coredump
17:39:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2052872
17:39:11 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/604
17:39:14 <adamw> #info Proposed Blocker, abrt, NEW
17:39:18 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
17:39:33 <adamw> btw, nielsenb gets a gold star for ticket voting on all of these
17:39:38 <adamw> and the rest of us get a lump of coal each
17:40:12 <lruzicka> +1 Finalblocker
17:42:31 <adamw> yeah, +1 too. graphical abrt is in both GNOME and KDE by default
17:42:34 <adamw> so the cited criterion works
17:42:42 <pwhalen> +1 Finalblocker
17:43:30 <adamw> proposed #agreed 2052872 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test", generating a coredump is definitely basic functionality
17:43:36 <lruzicka> ack
17:43:44 <bcotton> ack
17:43:48 <copperi[m]> ack
17:43:50 <coremodule> ack
17:44:08 <pwhalen> ack
17:44:32 <nielsenb> ack
17:44:57 <adamw> #agreed 2052872 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test", generating a coredump is definitely basic functionality
17:45:53 <adamw> #topic (2054226) Animated wallpapers are not correctly displayed in Gnome Shell 42.
17:45:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2054226
17:45:59 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/607
17:46:03 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:46:06 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
17:46:47 <coremodule> +1 final blocker based off stated criterion
17:46:59 <bcotton> +1 FB. It's less "not correctly displayed" and more "not displayed"
17:47:14 <lruzicka> +1FB
17:47:38 <adamw> well, this is slightly awkward
17:48:19 <adamw> we already have https://bugzilla.redhat.com/show_bug.cgi?id=2052654 as a beta blocker for
17:48:23 <adamw> '36 backgrounds aren't done'
17:48:38 <lruzicka> adamw, but no animated backgrounds work
17:48:44 <lruzicka> not even the old ones
17:48:44 <adamw> technically speaking, 'animated backgrounds don't work' isn't a blocker for 36 unless/until the 36 backgrounds turn out to be animated...
17:49:21 <nielsenb> Do we instead want to argue animated backgrounds are a basic functionality of gnome-control-center?
17:49:38 <nielsenb> Since I'm pretty sure Gnome ships one by default, and shows it in the chooser
17:49:44 <adamw> aha, never mind
17:49:45 * cmurf[m] arrives late, woops
17:49:49 <adamw> https://github.com/fedoradesign/backgrounds/commit/5aade4cc1ff3a982c589a49c11c45d6a99aa8ee7
17:49:53 <adamw> 36 backgrounds are animated
17:49:59 <nielsenb> Exciting
17:50:04 <adamw> so what i'm gonna suggest is, make 2052654 depend on this bug
17:50:11 <adamw> instead of accepting it in its own right
17:50:13 <adamw> that bug is intended to be a tracker already
17:50:27 <nielsenb> Makes sense
17:50:29 <lruzicka> there is also this issue, which I stumbled upon recently
17:50:31 <lruzicka> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4936
17:50:55 <lruzicka> which somehow suggest it may be possible to discard animated background
17:51:41 <bcotton> i could live with that suggestion
17:53:03 <adamw> lruzicka: that would also be an issue for openqa, heh
17:53:11 <adamw> i'll check with the devs if that's still an active idea
17:54:30 <lruzicka> so, shall we punt and wait?
17:55:15 <lruzicka> adamw, we would need to make some settings first before doing actual tests. Let's hope it will be possible.
17:55:53 <adamw> i was gonna say just agree to mark this as a dep of the tracker bug
17:55:54 <adamw> that makes it effectively a blocker because blocker status is transitive
17:56:01 <adamw> (though we don't display this very well in the app)
17:56:20 <adamw> so, let me formally propose this:
17:56:23 <nielsenb> https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2100/commits
17:56:35 <nielsenb> That MR includes removing animated background support
17:56:46 <nielsenb> So, I wouldn't expect it to persist into Gnome 42
17:57:06 <adamw> nielsenb: that's basically the same as the ticket
17:57:14 <adamw> it's by the same person who filed the ticket, and it's marked WIP
17:57:18 <adamw> so that doesn't mean it's going to happen
17:57:32 <nielsenb> I still support the just track it plan
17:57:40 <nielsenb> I'm just saying, don't be surprised
17:58:00 <nielsenb> Maybe ping the artwork people so they know?
17:58:20 <lruzicka> Well, this is somehow stupid, if the graphics team are working on an animated wallpaper and their work will be useless.
17:58:38 <lruzicka> such things should be announced quite some time ahead
17:59:26 <lruzicka> nielsenb, maybe let adamw ask first and then let them know
18:00:34 <adamw> proposed #agreed 2054226 - mark as blocking existing Beta blocker 2052654 - we already have #2052654 as a beta blocker tracker for "36 backgrounds not yet present". the 36 backgrounds are animated (they're checked into git already) so this bug would stop them working, so we can simply consider this bug as blocking that tracker. this makes it effectively a blocker, as blocker status is transitive
18:00:50 <lruzicka> ack
18:00:53 <nielsenb> ack
18:01:03 <coremodule> ack
18:01:13 <bcotton> ack
18:01:16 <copperi[m]> ack
18:02:44 <adamw> #agreed 2054226 - mark as blocking existing Beta blocker 2052654 - we already have #2052654 as a beta blocker tracker for "36 backgrounds not yet present". the 36 backgrounds are animated (they're checked into git already) so this bug would stop them working, so we can simply consider this bug as blocking that tracker. this makes it effectively a blocker, as blocker status is transitive
18:04:28 <adamw> #topic (2053627) Copy and paste do not work
18:04:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2053627
18:04:36 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/605
18:04:41 <adamw> #info Proposed Blocker, nautilus, NEW
18:04:43 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
18:05:52 <cmurf[m]> +1 final blocker
18:05:57 <bcotton> lruzicka: "This has been also reported upstream." can you add that link to the BZ? makes it easier to keep track of the upstream issue
18:06:11 <bcotton> +1 final blocker
18:06:25 <adamw> yeah, +1.
18:06:25 <lruzicka> bcotton, didn't I?
18:06:30 <lruzicka> let me fix it
18:06:32 <lruzicka> +1
18:08:05 <lruzicka> https://gitlab.gnome.org/GNOME/nautilus/-/issues/2149
18:08:36 <lruzicka> they closed it as a known issue https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/759
18:08:49 <lruzicka> but we should probably use the BZ for tracking anyway
18:08:58 <lruzicka> I will update it with those links
18:09:36 <adamw> proposed #agreed 2053627 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test"
18:09:40 <bcotton> lruzicka++
18:09:40 <zodbot> bcotton: Karma for lruzicka changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:09:41 <bcotton> ack
18:09:49 <nielsenb> ack
18:09:56 <cmurf[m]> ack
18:09:57 <coremodule> ack
18:10:21 <copperi[m]> ack
18:10:31 <lruzicka> ack
18:11:20 <adamw> #agreed 2053627 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test"
18:11:28 <adamw> #topic (2053790) Fedora look and feel is not fully applied on new installs
18:11:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2053790
18:11:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/606
18:11:38 <adamw> #info Proposed Blocker, plasma-workspace, NEW
18:11:41 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
18:12:59 <adamw> no criterion was cited
18:13:03 <adamw> and i'm not sure i can see one that applies
18:13:10 <coremodule> wondering the same thing myself
18:13:11 <cmurf[m]> i only briefly looked for a release criterion that applies, is look and feel basic functionality?
18:13:23 <coremodule> would we really block on this if it was the only one in the way?
18:13:29 <cmurf[m]> it could be viewed that way by UI folks
18:14:13 <bcotton> Conan Kudo: if you're around, it'd be good to have your input here
18:14:24 <Eighth_Doctor> hm?
18:14:56 <Eighth_Doctor> I consider it part of basic functionality, since Plasma Desktop's UI configuration is part of the basic setup
18:15:08 <Eighth_Doctor> it not working correctly can cause major graphical glitches
18:15:38 <adamw> stretching basic functionality feels like...a stretch
18:15:41 <nielsenb> So when you set the theme through a configuration tool, and it's applied incompletely?
18:15:44 <cmurf[m]> ok so there's missing function? it's not just that the UI/UX is wrong?
18:15:46 <Eighth_Doctor> yes
18:15:50 <adamw> if there is actual evidence of major graphical glitches, that'd be different
18:15:53 <Eighth_Doctor> the theme settings aren't working properly at all
18:16:01 <Eighth_Doctor> and SDDM text is gray on black
18:16:05 <cmurf[m]> so it's in some in-between state
18:16:05 <Eighth_Doctor> which is unreadable
18:16:29 <cmurf[m]> ohh
18:16:29 <Eighth_Doctor> you can see this by clicking on the drop down menus on the bottom left
18:17:14 <cmurf[m]> i'm tentatively +1 final blocker, screen shot might help
18:17:20 <cmurf[m]> being able to read menus is surely basic functionality
18:17:47 <nielsenb> Yeah, if some tool we install by default can manage themes, and that results in things being unreadable, that's a blocker
18:17:53 <adamw> i'd kinda like more substance on the practical effects, screenshots etc. would be handy.
18:18:01 <adamw> on the info in the bug now i guess i'd be a punt
18:19:10 <cmurf[m]> +1 punt, needinfo anyone for a screenshot demonstrating the problem (can be a vm)
18:19:23 <lruzicka> +1 punt
18:19:25 <nielsenb> I'm on board with a punt
18:19:27 <lruzicka> we still have time
18:19:35 <bcotton> +1 punt. i was going to oppose, but it sounds like there's some justification for taking it
18:19:36 <nielsenb> +1 punt
18:19:46 <adamw> note, openqa isn't helping us here ATM because openqa kde installs are still broken by https://bugs.kde.org/show_bug.cgi?id=449273 :|
18:20:00 <cmurf[m]> oh dear
18:20:36 <cmurf[m]> that itself seems blockery
18:20:59 <adamw> proposed #agreed 2053790 - punt (delay decision) - on the face of it this doesn't seem to violate criteria, but from meeting discussion it sounds like the bug may have significant practical consequences like unreadable text in default setups. we will ask the reporter to provide a bit more detail on the consequences, ideally with screenshots
18:21:02 <nielsenb> Didn't we accept that as a blocker already?
18:21:07 <nielsenb> ack
18:21:12 <lruzicka> ack
18:21:15 <cmurf[m]> ack
18:21:19 <lruzicka> nielsenb, I believe we did
18:21:24 <adamw> nielsenb: yes
18:21:30 <adamw> #agreed 2053790 - punt (delay decision) - on the face of it this doesn't seem to violate criteria, but from meeting discussion it sounds like the bug may have significant practical consequences like unreadable text in default setups. we will ask the reporter to provide a bit more detail on the consequences, ideally with screenshots
18:21:31 <bcotton> ack
18:21:34 <cmurf[m]> nifty
18:21:57 <adamw> unfortunately accepting it as a blocker doesn't magically make it go away and nobody can figure out what hte problem is yet :|
18:22:00 <adamw> anyhoo, next bug!
18:22:06 <adamw> #topic (2042877) crash happens on the newly installed system
18:22:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2042877
18:22:14 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/595
18:22:18 <adamw> #info Proposed Blocker, spice-vdagent, MODIFIED
18:22:21 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
18:22:38 <cmurf[m]> oh this is the thing that breaks copy paste between virt-manager VM's and hosts, isn't it?
18:23:13 <nielsenb> I think so, yes
18:23:48 <cmurf[m]> if i could, i'd be +10 beta blocker on copy paste being busted between guest and host, it's really aggravating
18:24:29 <nielsenb> This only just got reproduction steps, and I've been trying to figure that one out for a bit
18:24:43 <nielsenb> So I can't say for sure it's it, but it sure smells like it to me
18:24:44 <adamw> we've taken copy/paste bugs as FE before, not blocker
18:24:56 <adamw> and opinion still seems divided on whether this causes a crash alert on a fresh install, which is the criterion
18:25:57 <cmurf[m]> you know what, now that i think about it i did get an abrt notification in Shell but it only stayed up for a second (itself probably a blocker bug) and it wasn't listen in notifications list when clicking on date/time
18:25:59 <nielsenb> https://bugzilla.redhat.com/show_bug.cgi?id=2042877#c15
18:26:11 <nielsenb> I see that behavior, which is why I was -1 before
18:26:21 <nielsenb> I didn't double check to see if a crash actually happened
18:26:25 <nielsenb> It had, just no notification
18:27:01 <nielsenb> Which may be a bug in itself
18:27:19 <nielsenb> But again, limited time to poke at things this week
18:27:30 <nielsenb> Hate to open bugs I can't reproduce on demand
18:27:31 <cmurf[m]> what is a panel?
18:27:41 <adamw> i guess if the crash is verified real, it ought to produce a notification, so i can be +
18:27:42 <adamw> +1
18:27:43 <cmurf[m]> All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.
18:28:48 <cmurf[m]> i'm clearly +1 final blocker, if we need to clarify some criterion language then so be it
18:29:26 <cmurf[m]> we have a criterion for services enabled by default must not fail, but not one for "at first succeeds but the fails later"
18:29:27 <cmurf[m]> which is still really a fail
18:29:48 <cmurf[m]> *All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present. *
18:29:55 <cmurf[m]> s/. */.*/
18:30:11 <cmurf[m]> this is a system service, and while it starts OK it doesn't stay running ok
18:31:13 <adamw> proposed #agreed 2042877 - AcceptedBlocker (Final) - accepted as a violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop", it's not entirely clear whether this crash always triggers a notification but it seems to happen often enough to accept this
18:31:23 <lruzicka> ack
18:31:27 <nielsenb> ack
18:31:33 <cmurf[m]> Admiral Ackbar, please
18:31:33 <coremodule> ack
18:31:39 <copperi[m]> ack
18:31:41 <bcotton> ack
18:32:37 <cmurf[m]> looks like there's a fix in bodhi
18:33:23 <cmurf[m]> that's for 35 though, hmm
18:33:49 <cmurf[m]> oh there's one for 36 too
18:34:09 <adamw> #agreed 2042877 - AcceptedBlocker (Final) - accepted as a violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop", it's not entirely clear whether this crash always triggers a notification but it seems to happen often enough to accept this
18:35:56 <adamw> #topic (2006393) [DNS over TLS] following connection to a wifi AP, internet is not available for ~30s
18:35:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2006393
18:36:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/579
18:36:03 <cmurf[m]> ok don't read this 🙂
18:36:06 <adamw> #info Proposed Blocker, systemd, ASSIGNED
18:36:11 <adamw> too late, i read it
18:36:19 <cmurf[m]> it's a blocker by artifact of being set to NEW
18:36:39 <cmurf[m]> it was a blocker in f35 and when reopened it got made into a blocker accidentally for 36
18:36:56 <cmurf[m]> but as it turns out it might still be a blocker per comment 36 (the last one)
18:37:00 <cmurf[m]> so i'd say needinfo and punt
18:37:23 <nielsenb> Out of curiosity, what kind of wifi adapter is this?
18:37:35 <cmurf[m]> in my case intel
18:37:39 <nielsenb> I was seeing similar weirdness with IPv6 on a Qualcomm chipset one
18:37:48 <nielsenb> Well, fine
18:37:52 <adamw> i think it's more to do with the dns provider than the network hardware, isn't it?
18:38:02 <cmurf[m]> yes
18:38:04 <adamw> or the router...
18:38:06 <cmurf[m]> i think anyway
18:38:10 <nielsenb> No idea, in my case I swapped to an Intel and everything started working
18:38:33 <adamw> cmurf: i specifically re-nominated it, actually: https://bugzilla.redhat.com/show_bug.cgi?id=2006393#c23
18:39:22 <adamw> so the status is, for F35 we took it as a blocker on the basis that having to wait 30 seconds for network to start working on every boot and resume from sleep was unacceptable
18:39:32 <adamw> for F36, currently, the status seems to be that you have to wait about 12 seconds
18:39:35 <nielsenb> I wonder if I could reproduce with a script doing a bunch of resolve calls in a loop, suspend, and resume
18:39:50 <adamw> so, it's better. is 12 seconds Les Bad enough that it's no longer a blocker? discuss!
18:39:56 <nielsenb> Is that 12 seconds after a 'connected' icon appears somewhere?
18:40:13 <nielsenb> If yes, it's no less bad, still looks broken to a user
18:40:51 <adamw> cmurf?
18:42:51 <cmurf[m]> oops walked away
18:43:45 <cmurf[m]> i think it's a gray area at 12 seconds, it's not quite annoying but more of a frowny face that quickly resolved
18:43:59 <cmurf[m]> i'm more concerned now about whatever mcatanzaro is experiencing
18:44:29 <cmurf[m]> can ask in #workstation:fedoraproject.org
18:44:44 <nielsenb> It feels the same to me? If the little icon shows connected, and I go to Firefox and hit <F5>, and it doesn't load, it's broke
18:45:16 <nielsenb> Kind of weird dig works though
18:45:50 <adamw> cmurf: i was asking about the icon question
18:45:51 <cmurf[m]> the icon shows a ? during this time
18:45:56 <adamw> ok, so that's not awful
18:46:06 <nielsenb> Yeah
18:46:10 <cmurf[m]> not the )))) strength indicator of wifi
18:46:13 <adamw> i think i probably agree with mcatanzaro, at 12 seconds it's sucky but not blocking, would likely fail the last blocker test
18:46:27 <adamw> also agree that whatever he's seeing now is concerning, but we can handle that down the road
18:46:29 <nielsenb> It's 'annoying', not actively misleading the user
18:46:30 <cmurf[m]> thta's where i'm at, except i just read c34
18:46:32 <adamw> for now i guess i'm weak -1
18:46:41 <cmurf[m]> same
18:46:44 <adamw> beta FE is an interesting question...
18:46:46 <nielsenb> Yeah
18:46:47 <adamw> do we want to ship beta this way?
18:47:10 <cmurf[m]> no strong opinion if it can be fixed with an update other than it reduces complaints and confusion, maybe
18:47:24 <cmurf[m]> almost no one would hit it booting install media
18:47:52 <nielsenb> Kind of depends on the outcome of the testing in c34
18:47:56 <cmurf[m]> not least of which is that USB boots are slow enough that it means the bug surely won't present
18:48:08 <cmurf[m]> nor do folks do suspend
18:48:21 <adamw> i guess let's vote blocker for now and ask mcatanzaro in bug what he thinks about beta
18:48:28 <cmurf[m]> K
18:48:39 <cmurf[m]> -0.5 final blocker
18:48:51 <nielsenb> -1 final blocker
18:49:39 <adamw> proposed #agreed 2006393 - RejectedBlocker (Final) - this is still pretty bad if you're affected, but we think the reduction in the time it takes for the situation to resolve is sufficient that it no longer quite qualifies for release blocker status. we'll leave it up to the wisdom of the devs whether it's a better idea to revert the feature if it can't be fixed further
18:49:43 <cmurf[m]> mcatanzaro: I would say that issue is just not serious enough to be a blocker, but the change should probably be reverted regardless. Need to talk to Zbignew.
18:49:54 <lruzicka> ack
18:50:01 <nielsenb> ack
18:50:16 <adamw> cmurf: yeah, i'm counting that as a -1
18:50:18 <cmurf[m]> ack
18:50:26 <adamw> #agreed 2006393 - RejectedBlocker (Final) - this is still pretty bad if you're affected, but we think the reduction in the time it takes for the situation to resolve is sufficient that it no longer quite qualifies for release blocker status. we'll leave it up to the wisdom of the devs whether it's a better idea to revert the feature if it can't be fixed further
18:50:35 <adamw> okay, and that's the list!
18:50:38 <adamw> #topic Open floor
18:50:41 <adamw> any other business, folks?
18:51:24 <cmurf[m]> no update on the GRUB conditional blocker, i did start an upstream convo but not much in the way of concern by the developers - and also GRUB currently doesn't have a way to get/set efivars :\
18:51:31 <lruzicka> not from me :D
18:51:32 <cmurf[m]> so it's very unlikely to get fixed in Fedora 36
18:52:11 <nielsenb> That stinks
18:52:13 <cmurf[m]> meanwhile systemd-boot is getting this exact functionality in Fedora 36 🙂
18:52:17 <adamw> cmurf: ah, that's unfortunate
18:52:21 <cmurf[m]> it will be able to set BootNext in NVRAM
18:52:33 <nielsenb> Yeah, I really wish moving to that wasn't so controversial
18:53:14 <cmurf[m]> i think it's not terribly controversial itself, the issue is one of resources for adding support for another bootloader that also needs to be Secure Boot signed
18:53:29 <cmurf[m]> and currently shim hardcodes looking for GRUB as I understand it
18:54:00 <cmurf[m]> so it'd need shim changes, and Fedora infra changes to get sd-boot as a viable option let alone as a default for UEFI
18:54:03 <nielsenb> And the support burden of two bootloaders
18:55:03 <cmurf[m]> in a vacuum, perhaps not that significant - the bigger issues become upgrades, documentation, all the knock on effects
18:55:27 <cmurf[m]> and whether other editions would go for it, or would it just be an island of UEFI on the desktop using it
18:55:29 <nielsenb> Yup
18:55:51 <cmurf[m]> so yeah, i dunno
18:56:16 <adamw> anyway, thanks for the update
18:56:30 <cmurf[m]> np
18:57:55 <adamw> and thanks for coming, everyone
19:17:11 <adamw> #endmeeting